Таки Федор замочил негру. ТКО во втором раунде 1:48. Перед этим негра сделал рассечение носа у Федора. Мда... Тяжелый бой.

На Савеловском рынке семья дала мне десять минут на закупку гигабитного восьмипортового свитча D-Link и wi-fi роутера Linksys WRT54G2 v1. Решил остаться на протоколе g, хотя компьютер (по слухам) поддерживает и n тоже -- и роутер для n вдвое дороже, и выгоды непонятны, и наверняка с совместимостью что-нибудь будет не так. Уж ну его.

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

В прошлом месяце я употребил интернетов на 4.5GB. В этом месяце наверняка вернусь к прежней норме.

Vpri.org продолжает выкладывать новые тексты:

A Membrane with Parts: A new object model, Ted Kaehler

Supporting Actors in COLA, Michael Fig

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

Я вот думаю, что такое же нужно искать в деятельностном программировании: ситуативной инженерии методов. Нужны такие методы, которые были бы более-менее универсальны по отношению к целевой системе. Собственно, ISO 15288:2008 как раз такое и заявляет -- он работает независимо от размера системы, независимо от стадии жизненного цикла, независимо от уровня рекурсии в структуре системы.

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

Большое спасибо всем, кто дал мне советы по пользованию разными вариантами VPN для прослушивания pandora.com (http://ailev.livejournal.com/749592.html). Объявляем победителя: аноним, который посоветовал бесплатный и самый простой способ -- 1. скачать программу отсюда: http://www.hotspotshield.com/downloads/thank-you-RU/, 2. запустить и 3. слушать.

Регистрация на заброшенном аж в 2007г. эккаунте Пандоры прошла в один клик, и тут же полилась музыка давным-давно созданного мной Rob Dougan Radio. Смею вас заверить, качество диджейства Пандоры.ком неизменно превосходит все мои ожидания.

Как правильно пишут в интернетах, если у вас стоит баннерорезка (а у меня стоит Adblock Plus в FireFox), то никакой лишней рекламы вы не увидите. Tracert показывает, что ваш путь к счастью становится примерно на семь хопов длиннее, но это на глаз не слишком заметно.

Вполне ожиданно отвалилась отсылка писем. Поставил музыку на паузу, сказал программе OFF, отослал письмо, сказал программе ON, снял музыку с паузы -- все продолжилось.

Есть и неожиданности: Google для штатовского IP выдает другой порядок результатов поиска, хотя он меня вполне узнает и не требует никакого перелогинивания.

Enjoy.

Сегодня было организационное собрание по национальной инфраструктуре для ISO 15926 (немного об этом: http://www.slideshare.net/ailev/iso-15288-iso-15926), собрались представители восьми организаций (а от нескольких организаций пришли по двое, а то и по трое), причем два человека участвовали через Skype-группу. На этом собрании были рассмотрены итоги первого в стране двустороннего обмена данных в стандарте ISO 15926 между двумя разнородными базами данных при помощи софта iRing (http://www.youtube.com/watch?v=P224XeEonUM) и принято решение об институализации библиотеки справочных данных национального уровня.

Решили оперативно ставить сервер, разворачивать на нем iRing Sandbox, и стучаться затем в WIP RDL Sandbox FIATECH+PoscCAESAR от имени Инфраструктуры интеграции данных Русского института системной инженерии. Ну, или Совета интеграции данных этого института (с именем отделения еще определились неокончательно, равно как и с персональным составом координаторов).

После довольно бурной дискуссии было решено на первый раз ограничиться одной маленькой задачей: сделать templates для отечественной трубопроводной арматуры в объемах, достаточных для создания каталогов поставщиков. По мере сбора денег и других пожертвований порядок расходования средств таков:
-- материальная инфраструктура (сервера, софт, администрирование)
-- методические рекомендации по работе с iRing, учебники, технические рекомендации и прочее знаниевое обеспечение
-- организационные расходы, продвижение, конференции и т.д.: набор организационной массы
-- создание отечественных справочных данных (перевод ГОСТов в формат RDL, ибо никакая заграница нам в этом не поможет, а каждому отдельному поставщику это неудобно)

Так что национальной инфраструктуре справочных данных по ISO 15926 в стране быть, и скоро.

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

ISO 15288:2008 (определения):

Жизненный цикл -- эволюция системы, продукции, услуги, проекта или иного рукотворного объекта от замысла до прекращения использования.
life cycle -- evolution of a system, product, service, project or other human-made entity from conception through retirement.

Описание ЖЦ -- возможно организованный в стадии набор практик и мероприятий, связываемый с жизненным циклом, также служащий общим первоисточником для коммуникации и понимания.
life cycle model -- framework of processes and activities concerned with the life cycle that may be organized into stages, which also acts as a common reference for communication and understanding.

ISO TR 24748 (пордаздел 3.2.1) пишет об этом так:

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

Every system, whatever the kind or size, follows some life cycle model from its initial conceptualization through its eventual retirement. The progression of a system through the parts of the model, in whatever sequence or manner, is called the system's life cycle. The life cycle model, then, is a conceptual segmentation of the definition of the need for the system, its realization as a product or service, and its utilization, evolution and disposal. A system life cycle model is typically segmented by stages to facilitate planning, provisioning, operating and supporting the system-of-interest. These segments provide an orderly progression of a system through established decision-making gates to reduce risk and to ensure satisfactory progress. It is the need to make a decision to specific criteria before a system can progress to the next stage that is the most important reason for using a life cycle model.

На практике происходит традиционная путаница между объектом и его описанием -- та же самая, что между "процессом" и "описанием процесса", "онтологией" и "описанием онтологии".

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

Так, технический проект "жизненный цикл технологии" (technology life cycle technical project, TLCTP) рабочей группы по управлению жизненным циклом INCOSE (INCOSE Life Cycle Management Working Group, LCMWG. Я член этой рабочей группы.) в качестве первого пункта области своих интересов приводит определения терминов "новая технология" (emerging technology) и "жизненный цикл технологии" (technology life cycle). Тем не менее, в этом проекте приводится косвенное определение, в котором жизненный цикл технологии по факту является процессом, включающим все деятельности, относящиеся к разработке потребностей в технологии, разработку и доведения до зрелого состояния новых технологий, переход к использованию технологии в продуктах и услугах, мониторинг полезности/устаревания, и "выбрасывание" технологий (“technology life cycle” encompasses all activities relating to the development of technology needs, the development and maturation of new technologies, the transition/insertion of technology into products and services, the monitoring of technology usefulness/obsolescence, and the “disposal” of technologies).

В OMG SPEM 2.0 приводится следующее понимание жизненного цикла как процесса (самое начало раздела 9. Структура процесса):

Одна из наиболее общих характеристик, находимая во множестве различных определений процесса в литературе -- это определение последовательности стадий и контрольных точек, выражающих жизненный цикл разрабатываемого продукта
One of the most common characteristics found within the many different definitions of process in literature is sequencing of phases and milestones expressing a lifecycle of the product under development

Несмотря на то, что SPEM жестко разводит практики/методы и использование этих практик в качестве процессов, налицо путаница между процессом как описанием (life cycle model) и самим процессом (life cycle). Это нормальная практика, люди склонны путать символы и означаемое этими символами -- причем не только в речи, но и в действии (так, не задумывающиеся о подобных различениях люди регулярно целуют тряпку на палке, или две скрещенных дощечки). Даже OMG SPEM 2.0 (хвастающийся, что может описать любой жизненный цикл, также называющий его software process или delivery process) четко говорит, как описывается жизненный цикл: это процесс (примененные методы/практики/дисциплины), расписанный по стадиям, их конечным продуктам, и указанием контрольных точек.

Но тот же SPEM 2.0, говоря о "процессе поставки" (delivery process в терминах SPEM 2.0 и с учетом того, что этот жизненный цикл распространяется только на "проект", а не полный жизненный цикл системы), описывает не конкретный жизненный цикл, а "типовой" (класс жизненных циклов, которому в жизни будут соответствовать конкретные экземпляры):

Процесс поставки является специальным Процессом, описывающим полный и интегрированный подход для выполнения отдельными типами проектов. Он описывает полный жизненный тип проекта от начала до конца и должен использоваться как типовой для проектов, идущих с походими характеристиками, как они определены для процесса.
Процесс поставки является Процессом, который покрывает жизненный цикл разработки от начала до конца. Процесс поставки должен использоваться, как шаблон для планирования и ведения проекта. Он обеспечиваюет полное описание жизненного цикла с предопределенными стадиями, итерациями и мероприятиями, которые были детализированы путем [указания] последовательности ссылок на содержание методов в структурах разбиения. Он определяется на основании опыта прошлых проектов или занятий, и/или лучших практик разработки или подходов поставки. Он определяет, что произведится, как эти единицы производятся, и требуемый персонал в форме интегрированных Структур разбиения работы, рабочих продуктов и команды. Например, некоторый инженер по процессам может определить альтернативные Процессы поставки для проектов разработки программных средств, которые отличаются по масштабам занятости и вовлеченного персонала, типу разрабатываемых программных приложений, методам разработки и используемым приемам и т.д.
A Delivery Process is a special Process describing a complete and integrated approach for performing a specific project
type. It describes a complete project life cycle end-to-end and shall be used as a reference for running projects with similar characteristics as defined for the process.
A Delivery Process is a Process that covers a whole development life cycle from beginning to end. A Delivery Process shall be used as a template for planning and running a project. It provides a complete life cycle model with predefined phases, iterations, and activities that have been detailed by sequencing referencing method content in breakdown structures. It is defined on the basis of experience with past projects or engagements, and/or the best practice use of a development or delivery approach. It defines what gets produced, how those items are produced, and the required staffing in the form of integrated Work, Work Product, and Team Breakdown Structures. For example, a process engineer can define alternative Delivery Processes for software development projects that differ in the scale of the engagement and staffing necessary, the type of the software application to be developed, the development methods and technologies to be used, etc.

Так что нужно учитывать, что когда говорится об описании (model или description) жизненных циклов, чаще всего имеется ввиду описание не конкретного жизненного цикла, а типового жизненного цикла, и более того -- даже когда пропускается слово "модель", то тоже может иметься ввиду класс, а не его экземпляр. Тем самым в текстах по системной инженерии смешивается не только символ (описание, модель) и реальная жизнь, но и экземпляр (описания, модели) и включающий его класс. Тем не менее, все эти различения важны, когда речь идет о (компьютерном) моделировании жизненных циклов и порождении описаний проектов (например, в виде диаграмм Гантта) из моделей жизненного цикла. Поэтому слово "модель" хотелось бы зарезервировать для целей такого компьютерного моделирования, подразумевающего онтологическую точность, а слово "описание" использовать для всех остальных случаев рассказа о жизненном цикле (включая вариант опускания слова "описание").

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

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

Несколько лет назад, когда зачинался PraxOS, я много писал про паттерны, как форму накопления методического знания (тогда я еще не был знаком с ситуативной инженерией методов, а форму накопления и хранения методического знания найти очень хотелось -- ну, я и обратился к "языкам паттернов"). Сегодня тесная связь паттернов, методов, практик, дисциплин и процессов уже очевидна. Хотя очевидна только сама связь: особенности же явно требуют пристального внимания -- взять хотя бы разделение MethodContent, Process и Practice в SPEM 2.0 как три ортогональных друг ко другу типа шаблона).

В любом случае, литература по паттернам остается мне интересной. Вот, например, сегодня нашел книжку про применимость паттернов в системной инженерии -- Robert Cloutier, Applicability of Patterns to Architecting Complex Systems http://www.amazon.com/Applicability-Patterns-Architecting-Complex-Systems/dp/3836485877, 2008г. издания.

А для тех, кто не хочет покупать эту книжку в бумаге, замечу -- это просто (похоже, урезанное на ненужные "приложения" с результатами опросов "в поле") издание диссертации 2006г., а диссертации обычно свободно лежат в Сети. Получите удовольствие: http://sse.stevens.edu/fileadmin/sse/academics/dissertations/Cloutier_Thesis_2006_PatternsAndComplexSystems.pdf

Свежие мысли Robert Cloutier про паттерны в весьма вяло ведущемся его блоге: http://sepatterns.typepad.com/.

Инженерия методов (method engineering, http://en.wikipedia.org/wiki/Method_engineering -- и нужно понимать, что, как обычно, из программной инженерии method engineering стремительно перемещается в системную инженерию) относится так же к методологии, как системная инженерия к системному мышлению (теории систем). Напомню: Harold Lawson предложил схемку, при которой инженерия -- это движение от придуманных концепций к их воплощению в реальных системах, а системное мышление изучает реальность и придумывает соответствующие ей концепции.

Примером приложения инженерии методов к системной инженерии служит сам стандарт ISO 15288, который определяет (в соответствии с метамоделью ISO TR 24774) набор практик (методов, дисциплин, паттернов) системной инженерии в целом -- практики определения требований заинтересованных сторон, анализа требований, архитектурного проектирования и т.д. Затем в этом же стиле MFESA (Method Framework for engineering system architecture, формально текущая версия описана в книге: http://www.freebookspot.in/Books-Method%20Framework%20for%20Engineering%20System%20Architectures.htm и в подробной презентации: http://www.sei.cmu.edu/library/assets/mfesatutorialoneday20090420.pdf) определяет практики работ по архитектурному проектированию -- планирование и обеспечение ресурсами архитектурных работ, определение влияющих на архитектуру факторов, создание начальных архитектурных моделей, определение возможностей для повторного использования архитектурных элементов и т.д.. Легко можно предположить третий уровень уточнения, на котором описывается не только, что нужно делать, но и как нужно делать, например, определение возможностей для повторного использования архитектурных элементов (Task 4 MFESA) в заданном инструментальном окружении.

На каждом уровне происходит детализация требований к выполнению работы. Так, ISO 15288 не требует никаких "оценочных дел" (это требует ISO 15026, в котором указано, как он связан с ISO 15288). Но вот MFESA конкретизирует требования "оценочного дела" и описывает методы/практики/дисциплины/паттерны, связанные с "делами архитектурного качества" (architectural quality case).

Другой пример: практики жизненного цикла ISO 15288 на верхнем уровне, уточнение практики планирования проектов по Голдратту на втором уровне, и уточнение практики определения и документирования начальной длительности буфера проекта при использовании конкретного голдратт-совместимого софта управления проектами в условиях конкретной организации.

Ситуационная инженерия методов (situational method engineering) имеет под собой ту идею, что метод выполнения работ нельзя задать заранее: каждая система уникальна, имеет свой собственный уникальный жизненный цикл, и поэтому каждая из систем требует для себя уникального метода работы. Утверждается, что какие-то кусочки/фрагменты методов все-таки можно осознать и хранить для повторного использования, но для конкретной системы из таких кусочков нужно "по ситуации" собирать ее уникальный метод, который будет продвигать эту систему по ее уникальному жизненному циклу, учитывая уникальную специфику этой системы и уникальные риски в соответствии с ситуацией. Тем самым утверждается, что людям нельзя дать универсальный метод, но можно дать "конструктор методов" с достаточным количеством этих кусочков/фрагментов, который позволит сплести (weaving) необходимый специализированный метод по потребности.

Это означает, что "горбатую диаграмму" (hump diagramm) можно рисовать не только для применений (не путаем описание самой практики, и ее применение в развертке по времени!) первого уровня разбиения работ по дисциплинам/практикам/методам, но и для дисциплин/практик/методов второго уровня. Вот, например, классика жанра -- горбатая диаграмма набора методов (методологии) RUP для всего процесса:


Вот диаграмма для архитектурной работы по MFESA:


Пара определений (по мотивам онтологий MFESA и SPEM):

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

Процесс -- это способ, которым выполняется работа "в жизни". Можно сказать, что процесс -- это применение метода, происходящее-длящееся в конкретный интервал времени (и тем самым тесно переплетенное с применениями других методов). Процесс -- это всегда развертка во времени. Впрочем, описания процесса тоже могут быть повторноиспользуемы: тогда говорят о "шаблонах процесса" (в SPEM это capability patterns).

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

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

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

На сегодняшний день ситуация существенно изменилась, хотя положение нельзя назвать удовлетворительным:
-- существует огромное количество разных "наборов методов", они есть на все случаи жизни.
-- все эти "наборы методов" описаны абсолютно по-разному, эти описания не придерживались никакой мета-модели. Есть совсем немного разных мета-моделей для ситуационной инженерии методов: ISO 24744, SPEM, OPEN/OPFG, ad hoc UML схема, SMSDM ("австралийские вариации" из http://ailev.livejournal.com/749986.html), неявная метамодель (когда люди "пишут единообразно" внутри себя, но не публикуют описания правил достижения этого единообразия), отсутствие метамодели.
-- по факту существует только один вариант доступного полупопсового инструментария, подразумевающего обмен моделями методов: для метамодели OMG SPEM 2.0. Во всех остальных случаях приходится пользоваться результатами академических разработок, или какими-то "настройками" к разным моделерам общего назначения -- что явно не подразумевает обмена результатами работы по моделированию методов.

В рассмотренном нами примере ISO 15288 придерживается метамодели ISO 24774, а MFESA придерживается метамодели OPEN (впрочем, OPEN -- это упрощенный вариант ISO 24774). Для OPEN есть огромный репозиторий кусочков методов (я писал уже о нем как о "родственнике PraxOS" -- http://ailev.livejournal.com/674073.html) с 1100 описаниями отдельных методов, выполненных в соответствии с метамоделью OPEN: http://www.opfro.org. Одна беда: никакого инструментария для поддержки создания кусочков методов (method authoring) для этого огромного репозитория нет, никакого инструментария для сборки нужных для данного проекта методов и описания их применения в ходе жизненного цикла системы тоже нет. Все "руками", и поэтому данная инициатива практически мертва на сегодня.

Метамодель SPEM всем хороша, но у нее есть несколько существенных недостатков:
-- в ней не предполагается многоуровневости описания методов, аспект-ориентированного многоуровневого плетения. Любой перескок с уровня на уровень (например, сделать шаг делом, а дело превратить в мероприятие) представляет собой проблему.
-- нет совместимости с ISO TR 24774, а стандарты описания методов/практик системной инженерии используют именно этот подход (как ISO 15288, так и в какой-то мере MFESA. И это вряд ли изменится: сама проверка соответствия стандарту чаще всего проходит по ISO 15504, и ISO TR 24774 сам вырос из результатов дискуссий о том, как проверять выполнение методов в процессах. Авторов SPEM волновали совсем другие вопросы: их много больше волновало, как соединить описания методов с описаниями процессов)
-- ничего не говорится про "оценочное дело" (разве что можно указать такой артефакт)

Поэтому по факту вся ситуативная инженерия (чаще всего это разные вариации на тему RUP, облегченного агилизированного варианта OpenUP, eXtreme programming, SCRUM и прочих "софтверных процессов" -- см. http://www.eclipse.org/epf/) проходит сегодня с использованием SPEM-инструментария, а ситуативная инженерия методов соответствующей стандартам ISO "настоящей системной инженерии" либо вообще не происходит (что прямо противоречит требованиям этих стандартов), либо происходит "вручную", т.е. запредельно медленно и дорого.

Отсюда выводы и программа ближайших работ:
-- нужно создать русскоязычную терминологию для говорения о ситуативной инженерии методов.
-- нужно исхитриться описывать методы/практики/дисциплины/паттерны, соответствующие метамодели ISO 24774 (т.е. стандарты практик системной инженерии) с использованием метамодели SPEM (создать специальный "метод описания методов")
-- создать архитектуру репозитория кусочков/фрагментов методов PraxOS, пригодного для многоуровневого уточнения методов (в том числе методов системной инженерии, ибо есть и другие интересные для PraxOS методы -- например, дидактические методы, психотехнические методы и т.д.)
-- создать начальную библиотеку методов PraxOS (ISO 15288, ICM, Голдраттовское планирование проектов, MFESА и т.д.) на русском языке
-- внимательно отслеживать появление инструментария, соответствующего другим метамоделям и принять активное участие в международной инициативе SPEM 3.0, исправляющей самые вопиющие недостатки текущей метамодели (наверняка эта инициатива есть, ее только нужно найти и поддержать).
-- предоставить полностью русскоязычный инструмент для ситуативной инженерии методов (т.е. гармонизированно перевести документацию/хелпы к EPF Composer).

Леонид Каганов: "Запомни крепко: в доме не свистят. Не будет денег. Так гласит примета. И постепенно смысл приметы этой становится понятен всем подряд. Пока ты в доме исполняешь свист, ты нарушаешь авторское право. И в дверь твою уже стучится РАО и говорит, что ты рецидивист. Ты нарушаешь авторский закон. Не верите — спросите у юриста: есть автор у исполненного свиста, и даже не беда, что умер он. Так даже проще — чтобы не мешал. И пусть при жизни он не знал про РАО, но РАО восстановит честь и право, устроив юридический скандал. Он умер, но мелодия живет. А там, глядишь, и родственники живы. И вместе с РАО требуют поживы с любого, кто свистит и кто поет." (и там такого много: http://kaganov.f5.ru/post/88793).
* * *
Ближневосточный "Рахат-Лукум" на Третьяковской пару недель назад преобразовали в итальянский Pronto. На мой вопрос официантке про замену кухни она ответила: "нет, вся кухня осталась, может только один человек поменялся". Но плова и харчо в меню больше нет, безжалостно поменяны на макаронные изделия и овощные супчики -- ни одного прежнего блюда не осталось, кроме кальяна (если, конечно, его можно считать блюдом). Порции уменьшились, цены поднялись.
* * *
Заяц разъелся так, что у него брюхо стало круглым. Впрочем, это же относится и к морским свинкам, и даже к нашему Мышане.
* * *
Неожиданно приятная музыка: http://www.ilike.com/artist/BETTA+BLOCKER (осторожно, у этой музыки сложно найти мелодию, не всегда есть ритм, ну и так далее). На грани между тем музаком, под который еще можно работать, и той музыкой, под которую работать уже нельзя. У меня бывают периоды, когда я слушаю такую музыку сутками.
* * *
Суббота и воскресенье -- много-много исследовательской работы, "читал интернеты, много думал". А сегодня весь день в диспетчерском режиме: телефоны, назначения дат, переговоры, письма.
* * *
Японцы проехали на одноместном солнцемобиле (6м2 панелей) 3000км по Австралии со скоростью практически 100км в час, не используя никаких других источников энергии, кроме солнца -- http://www.wired.com/autopia/2009/10/world-solar-challenge/. Серийно выпускающийся Tesla motors электромобиль Roadsters прошел на одной зарядке 500км, тоже в Австралии -- http://www.teslamotors.com/media/press_room.php?id=2022. Это к вопросу о возможностях сегодняшних технологий.

Будущее уже здесь, только оно пока очень дорого стоит.

Я рассматриваю работы vpri.org как лидирующей организации по программированию-в-малом (а то, как они это решают -- это и моделирование-в-малом). Они решают вопрос "как мало нужно сказать железу, чтобы оно поняло, что от него нужно".

How do you find the Sine function, if you don't know its name?, Ted Kaehler

Chains of meaning in the STEPS system, Ian Piumarta

An Assembler for AVM2 using S-Expression, Takashi Yamamiya

High-level Expressions in Language L, Hesam Samimi

Research Summary: A Programming Methodology and A Reliability Mechanism, Hesam Samimi

COLA Kernel Abstraction, Ian Piumarta

A Lazy List Implementation in Squeak, Takashi Yamamiya

Register Allocation via Puzzle Solving via Planning, Hesam Samimi

RCCola: Remote Controlled Cola, Takashi Yamamiya

Recognizing the CAICO, A Collection of Almost-Identical Complex Objects, Ted Kaehler

BabySteps: An approach to bootstrap an interactive system on COLA, Yoshiki Ohshima

Quantum Object Dynamics, Ian Piumarta

А вот SOA -- это программирование-в-большом. Я не очень понимаю, кто сейчас лидер в этой области: "как мало нужно сказать, чтобы описать другие автономные программы, и как мало нужно сказать, чтобы эти другие программы поняли, как им слипнуться для общей цели". Пока присматриваюсь к моделям-в-большом от группы AtlanMod (http://www.emn.fr/z-info/atlanmod/index.php/New_Results) и практическим разработкам типа Dassault Systemes V6, я писал об этом неделю назад -- http://ailev.livejournal.com/748188.html.

Я вот думаю сейчас, что эти такие разные большие-малые программирования-моделирования (с размытой между ними всеми границей) очень похожи на проектирование и конструирование в нынешних инженерных проектах. Когда-то "просто инженер" сейчас -- либо инженер-конструктор (с ЕСКД, прошитой в голову), либо инженер-проектировщик (с прошитой в его голове СПДС). Эта разница отражалась и софтом, и ВУЗами, и повадками.

Но онтологические САПР позволяют сегодня преодолеть разницу между конструированием и проектированием (например, в CATIA начиная с V5 проектирование и конструирование ведутся в одном окошке, между этими режимами работы по факту нет переключения). Я думаю, что language workbenches становятся такими же мостиками между двумя (а то и всеми четырьмя, если учесть моделирование) уже успевшими разойтись и теперь настоятельно нуждающимися в склейке программистскими-модельерскими "в малом" и "в большом" мирами.

И тут нужно вспомнить, что одна из идей всех этих COLA и STEPS из vpri.org -- создание компактной и удобной системы для многоязыкового мультипарадигмального программирования. Что это, если не language workbench?! Но аборигены vpri.org не пользуются терминологией от Martin Fowler, они и сами с усами.

(это слайд из http://www.slideshare.net/ailev/ss-2290189).

Для того, чтобы в крупных проектах избежать основных ошибок координации работ между менеджерами и инженерами требуется минимально три артефакта:
-- модель жизненного цикла
-- требования
-- "оценочное дело"

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

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

Для того, чтобы понимать, какие именно это стадии жизненного цикла, и какие требуются содержательные артефакты (состояние системы на конец стадии -- проект, или прототип, или готовая система), а также для фиксации самого факта наличия пересмотра выделения ресурсов между этими стадиями необходимо иметь описание (лучше -- компьютерную модель) жизненного цикла. Требование иметь это описание есть в ISO 15288, а в руководствах к нему (ISO TR 24748-1 и ISO TR 19760) рассказывается о том, что между стадиями происходит пересмотр выделения ресурсов, т.е. происходит принятие решения о том,
-- выделить ли ресурсы для перехода к следующей стадии,
-- продолжить ли выполнение текущей стадии в счет уже выделенных ресурсов, или небольшой добавки ресурсов, достаточной для получения результатов, позволяющих принять решение о выделении ресурсов для перехода на следующую стадию
-- закрыть проект (признать, что дальнейшее выделение ресурсов нецелесообразно0

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

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

Когда говорится о "требованиях", то имеется ввиду:
-- разные виды требований (прежде всего -- заинтересованных лиц, к числу которых прежде всего относим менеджеров; требования к системе, определяющие границы системы)
-- текущее понимание требований: переговоры между менеджерами и инженерами идут в течение всего хода проекта, а не только в самом начале проекта. Поэтому требования фиксируются на предыдущем пересмотре выделения ресурсов (базис, baseline), чтобы команда инженеров могла спокойно работать всю стадию N до текущего пересмотра ресурсов. В то же время, всю эту стадию N требования пересматриваются, и к пересмотру готовится новый набор требований -- который будет зафиксирован на новую стадию N+1. Ибо менеджерам выделять деньги на продолжение реализации устаревших требований "по состоянию на конец стадии N-1" было бы неправильно: в ходе выполнения стадии N были получены новые знания, и требования просто обязаны быть откорректированы. Инженеры и менеджеры должны поэтому договориться о пределах этой корректировки, и как эта корректировка может повлиять на бюджет, сроки и риски проекта в целом.

ISO 15288 не рассказывает об этой работе с требованиями, он просто фиксирует необходимость наличия разных видов требований, а также необходимость трассировки этих требований к разным заинтересованным сторонам -- и постулирует непротиворечивость требований к системе (что означает, что заинтересованные стороны должны по этим требованиям договориться). Работа по непрерывному изменению всех видов требований в ходе всего жизненного цикла и недопустимость замораживания начальных требований оговаривается практически всеми методами управления жизненным циклом. Метод постадийного выделения ресурсов (ICM) конкретизирует, что
-- должна проводиться процедура фиксации требований на каждую следующую стадию N+1, но фиксируемый вариант должен уточняться в ходе всей предыдущей стадии N
-- возможность выполнения требований в ходе проекта должна доказываться инженерами менеджменту в моменты пересмотра выделения ресурсов.

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

Это замечание очень похоже на разницу оценка успеха проекта "традиционным" управлением проектами (анализ освоенных объемов), а оценки "по Голдратту" -- оценки того, когда проект будет выполнен. Менеджеров интересует не успех предыдущей стадии, а успех будущей стадии (помним: в этот момент происходит выделение ресурсов на будущую стадию N+1. Ресурсы на предыдущую стадию были выделены при предыдущем пересмотре выделения ресурсов после стадии N-1 и перед стадией N. Поэтому интересуют риски продолжения проекта, а не то, насколько справились инженеры с выполнением задач предыдущей стадии -- менеджеров интересует оценка будущего, а не оценка прошлого).

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

Слово "доказательство" (а не сверка, проверка и т.д.) тут не случайно: в какой-то момент в методе ICM пришлось менять термин на "доказательство", ибо все другие термины позволяли инженерам просто предъявлять результат работы ничего не понимающим в содержании менеджерам, и тем самым их ошибки становились очевидными только на самых поздних стадиях проекта, когда исправлять их было уже поздно. ICM прямо говорит, что должна быть продемонстрирована очевидность (evidence) приемлемости рисков продолжения проекта.

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

Менеджеры выделяют достаточно средств, чтобы инженеры вели это "оценочное дело". В момент пересмотра выделения ресурсов менеджеры кроме самой целевой системы в соответствующем законченной стадии жизненного цикла состоянии получают тем самым
-- обновленные требования
-- оценочное дело.

Поскольку сами менеджеры читать оценочное дело не в состоянии, они поручают проверку оценочного дела независимым инженерам (ибо инженеров-разработчиков на свои доказательства глаз замылен). Независимые инженеры после знакомства с оценочным делам сообщают менеджерам, какие риски продолжения проекта. Менеджеры, заслушав и мнение инженеров-разработчиков, и независимых экспертов, принимают решение о выделении ресурсов (пересматривают в части предстоящей стадии ЖЦ принятое в начале проекта решение о выделении ресурсов на весь проект, включающий много стадий).

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

Method engineering развивается и предлагает самые разные софтопроцессные (читай -- жизненноцикловые) метамодели: SPEM, OPF, OOSPICE, SMSDM. Фишкой тут является соединение жизненноцикловых менеджерски-ориентированных "макропроцессов" и используемых в конкретные моменты работы инженерно-ориентированных "микропроцессов" (подробнее -- http://www.icsp-conferences.org/icsp2009/PDF/B4/Zhu_ICSP2009.pdf, в том числе описание трудностей такого синтеза в рамках формализма SPEM. Впрочем, эти трудности мне вчера долго рассказывал vvagr, безо всякого знакомства с этой презентацией).

По факту среди методных инженеров (о, великий русский языка!) победил SPEM: и сама метамодель оказалась удачна, и выбор метамодели определяется наличием свободного мощного инструментария (EPF Composer). Современные лекции по методологической инженерии читаются в конечном итоге на примере SPEM (очень хорошее введение в проблематику -- http://www.uio.no/studier/emner/matnat/ifi/INF5120/v09/undervisningsmateriale/F07-020309-Method-Engineering-be.pdf, хотя эту ссылку я уже давал, но с удовольствием повторю).



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

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

Понятно, что все эти понятия нужно пересмотреть, ибо в том же SPEM, выделяют method content (те самые "приемы"), process и practice -- причем practice "ортогональна" и приемам, и процессам, и представляет собой описание каких-то аспектов, общих для многих приемов и процессов. Это все удивительно, но когда я слышу "аспект", я просто понимаю, что речь идет не об изложении какой-то последовательности, а о "плетении" (weaving) -- так что практики я считаю теми же приемами, только не поддающимися "процессному" выстраиванию в явную последовательность, а подразумевающими аспект-ориентированное "вплетение".

Впрочем, все эти "процессы" более пригодны именно для машинного исполнения, или должны пониматься как очень крупная нарезка. Люди все приемы выполняют в режиме "плетения", а не строго следуют "процессу" на нижнем уровне.

В системной инженерии SPEM использовался как-то для моделирования и последующей адаптации EIA-632: невнятный текст, сводящийся к пересказу введения в SPEM со словами "системная инженерия" http://www.lattis.univ-toulouse.fr/uploaded/files/publications/conferences/EXPPAND08_V01b.pdf и hмного более подробный http://tel.archives-ouvertes.fr/docs/00/34/60/37/ANNEX/soutenance_en.pdf (впрочем, эти ссылки я уже давал где-то полгода назад). В этих работах показывается традиционная архитектура "метода создания метода":
-- берем крупнонарезанные практики и жизненный цикл "из Стандарта системной инженерии". Это отраслевой уровень.
-- уточняем мелконарезанными практиками и стандартами выполнения отдельных работ (инженерии требований, управления информацией и т.д. -- отвечаем на вопрос "как именно", по какой методологии это все делаем). Это уровень выбранных предприятием методов работы.
-- уточняем, какой конкретный инструментарий, жизненный цикл и связанные с ним особенности будут использоваться в ходе конкретного проекта (экземпляра ЖЦ) по работе с конкретной системой, учитывающие уже все технологические особенности и риски именно этого проекта.

Для стандарта системной инженерии EIA-632 (140 страниц текста) получилось 69 пакетов методов, 79 диаграмм, 1534 элемента, 1502 связи. Моделировали прямо в UML стереотипами SPEM.

Для того, чтобы лучше понять достоинства и недостатки SPEM, нужно ознакомиться с критикой этой метамодели и конкурирующими проектами. Наиболее активны тут австралийские вариации на тему улучшения SPEM в рамках исследований по situational method engineering:

Bhuvan Unhelkar, 2009: http://www-staff.it.uts.edu.au/~brian/Module2_6perpage.pdf (учебный курс Module-2)
Brian Henderson-Sellers, 2006: http://emmsad06.idi.ntnu.no/EMMSAD06_p6-henderson.pdf
Brian Henderson-Sellers, 2005: http://www.pa.icar.cnr.it/cossentino/al3tf3/docs/hs.ppt (FAME Project)
Cesar Gonsalez-Perez, Brian Henderson-Sellers, Tom McBride, 2004: http://www.verdewek.com/work/Download/Seminars/COTAR-May04-IntroSMSDM.ppt

Это все из проекта по стандартизации процесса построения агентской архитектуры FIPA. Похоже, что именно этот подход (а не SPEM) лег в основу ISO 24774, и тем самым ISO 15504 и ISO 15288. Но софтовых инструментов пока не найдено.

Эти работы продолжаются. Например, в 2009г. вышла статья "A method to build information systems engineering process metamodels", где приводится ряд мета-моделей процессов (activity-, product-, decision-, context-, strategy-oriented) и описываются проблемы их синтеза. Вот еще презентация -- http://www.icsp-conferences.org/icsp2009/PDF/B4/Zhu_ICSP2009.pdf

Тем временем, в агентской архитектуре таки победил SPEM -- в том числе он был оттестирован австрало-итальянской командой на возможность описания не только ОО-процессов, но и процессов самоорганизации в агентских системах -- моделирование пяти разных методов в SPEM http://www.dcs.bbk.ac.uk/research/techreps/2009/bbkcs-09-05.pdf, и чуть менее доступная работа http://portal.acm.org/citation.cfm?doid=1363686.1363853.

Google запустил новый музыкальный поиск, но мне он недоступен -- наверняка потому, что я ищу музыку из России и какие-нибудь дурацкие лицензионные ограничения запрещают Гуглю спеть мне колыбельную на ночь или рок-н-ролл к завтраку.

Я вот думаю, почему бы российским провайдерам (пока из России не сделали интернет-аналог Китая вместе с его Великим Китайским Брандмауэром) не предоставлять за небольшую денежку иностранный IP для обхода этих дурацких ограничений? Это ведь технически обеспечить очень просто, "все умные роутеры делают это". Интересно, сколько бы стоило купить себе внешний IP из какой-нибудь сетки США. Вряд ли более доллара в месяц.

UPDATE: про головную боль с бесплатными прокси я знаю, просьба их не предлагать. Для бешеного сисадмина и пять прокси не крюк.

Сейчас PraxOS имеет формат вялоструктурированного и полузаброшенного вики-сайта (http://praxos.ru), но поскольку PraxOS -- это набор методов ("как делать"), его основная часть легко может быть преобразована в библиотеку Method Plug-in в каком-то из моделеров SPEM 2. Это позволит непосредственно применять PraxOS при создании набора жизненных циклов (процессов) КонКорга путем задействования подходящего SPEM-моделера и разработки адаптированных для КонКорга Method Configurations.

Чего в этот суп хотелось бы добавить:
-- BPMN2 вместо activity diagram из UML. SPEM 2 это позволяет, но моделеры еще нет.
-- SBVR в полном объеме (словари и правила).
-- универсальность моделирования (особенно в части моделирования work products и организационного моделирования). Понятно, что это не UML, это про онтологические модели и ISO 15926 (ну, или что-то типа MatrixOne от Dassault Systemes, но свободное).

Хотя и без этих будущих вкусностей к SPEM-моделированию PraxOS вполне можно приступать. Впрочем, уже приступили.

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

Софт, разъяснения и примеры: http://www.eclipse.org/epf/

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

Тем не менее, время от времени происходит что-то интересное. Например, Xerox изобрела серебряные чернила. Теперь у Xerox есть диэлектрик (пластик), печатаемый (свежеизобретенный) проводник, и ранее изобретенный (но тоже немного улучшенный) полупроводник. Можно начинать печатать интегральные схемы на принтере, безо всякой "чистой комнаты" -- http://www.reuters.com/article/pressRelease/idUS190895+27-Oct-2009+BW20091027.

Бетонная печать тоже процветает -- http://www.d-shape.com/ (а год назад в это направление добавили еще денег: http://gizmodo.com/5045863/concrete+jet-printer-gets-caterpillar-funding-print+out-houses-on-the-way).

Самые разные принтеры появляются и дешевеют, о них уже заботиться не нужно. Я думаю, что сейчас нужно заботиться о редакторах -- редакторах текстов, редакторах микросхем, редакторах домов. Проблема сейчас та же, что была с редакторами текстов: когда-то я работал со строчным редактором, в котором зато была командная строка, а язык этой строки напоминал помехи в тракте радиопередачи (это выражение впервые я услышал как раз про этот язык текстового строчного редактора). А сейчас набираю этот текст в Семажике, в котором командная строка отсутствует, но зато WYSIWYG. Я думаю, что в системах типа CATIA V6 нужно увидеть этот самый строковый редактор, с которым могли работать только Очень Умные Спецы. И изобрести нормальный WYSIWYG для средних чайников -- что бы это ни значило для такого сорта "редактора". А потом распечатывать итоги работы на ближайшем подходящем принтере, ругаясь, что опять бетон вовремя не подвезли, да и микросхемный картридж надо бы уже заменить, а то вот-вот кончится...

Я сделал очередной (третий) апдейт слайдов по координационным между менеджерами и инженерами артефактам жизненного цикла -- http://www.slideshare.net/ailev/ss-2290189.

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

Есть и вариант обращения к специализирующейся на расшифровке аудио фирмы (например, http://www.stenografistka.ru/correct.html), но литературная обработка без понимания сути вопроса -- это сомнительное дело. Хотя есть вариант устроить pipe -- сначала бессодержательные расшифровщики, а потом содержательное редактирование терминологии и структуры текста.

Понять бы еще, как это организовать. Проще всего с помещением -- читать можно прямо в офисе на видеокамеру (на видеокамеру, чтобы можно было потом тычки в экран или флипчарт превращать в слова). Хуже -- со временем. По моей прикидке, у меня материалов примерно на 50 часов, это примерно соответствует 1000 страниц текста. А хотелось бы это все сделать быстро. Понятно, что бессодержательная расшифровка занимает примерно сутки (все сайты хвастаются, что могут одолеть до 17 часов записи в сутки), а вот сколько занимает редактирование-структурирование -- пока непонятно.

Нужно будет поставить эксперимент, и выпустить первых 100 страниц (это 5 часов разговора). Если эксперимент будет удачным, можно будет продолжить -- и скоро нельзя будет сказать, что по-русски ничего по системной инженерии не написано. Если эксперимент будет неудачным, то нужно еще подумать, как мою бессвязную речь превращать в связный текст.

Завтра займусь.