Понедельник утро
Следующий шаг в морском бурении: бурильную установку поместят прямо на морское дно, где она будет работать в автономе. Для этого нужно создать такую систему управления бурением, которая сможет работать абсолютно автономно, без оператора -- и четырехлетний проект по доказательству осуществимости такой системы как раз начинается (https://trac.posccaesar.org/wiki/ProjectGoal). SOA, агенсткие архитектуры, ISO 15926 и онтология, и так далее со всеми остановками.
Когда я вчера писал про "общие курсы" (http://ailev.livejournal.com/625203.html), я этого еще не видел. Но рад -- не ошибся. Ибо знание про собственно tripping (спускоподъемную операцию для заметы бурового долота) специфично, а вот технологии для построения системы управления такими операциями используются везде, они абсолютно неспецифичны.
* * *
На Музыка Москва 2008 так и не пошел. Вместо этого поиграл полчаса на клавишах -- попробовал несколько новых комби (комбинация звуков под управлением Карма), традиционно восхитился. И по поводу похода на эту выставку опять вспомнил любимую свою картинку:
* * *
Ввязался в споры по выбору фотоаппарата для любительской съемки (любительская -- это когда снимаешь уже не случайно, вспомнив о камере в телефоне или завалявшейся в сумочке мыльнице, а намеренно. Но не сильно фанатеешь и не зарабатываешь на этом). Вдруг кому еще интересно: http://ella-p.livejournal.com/847762.html. Суть моей рекомендации: Panasonic G-1, поступающий в продажу как раз в октябре-ноябре -- ибо определяющим параметром являются размеры и вес при малой (4-5, а не 25-35) пиксельной плотности матрицы. Желающие проверить эту рекомендацию -- покопайтесь в базе данных фотоаппаратов на http://www.dpreview.com/ (четвертая строчка меню в правом верхнем углу).
Дискуссия о фотоаппаратах мне очень напоминает дискуссию о фортепианных клавиатурах (всегда находятся как сторонники пальцы ломать об тяжелые деревяшки клавиш, так и сторонники качать бицепс тасканием громоздких и тяжелых камер. Традиции, они и есть традиции. Автомобиль должен повторять формой телегу, так? И вместо руля ему желательно приделывать вожжи -- они ведь "так удобно сидят в руке").
* * *
Самое большое напряжение мысли -- это перевод знания о предмете (всегда неполного!) в план хоть каких нибудь действий. А потом попытки воплотить этот план в реальность. Ибо так легко извинить себя в том, что ничего не понимаешь, и найдутся понимающие люди, которые что-то тебе подскажут -- нужно просто найти их, повстречаться, и все само устроится. Опыт показывает, что находятся люди, но понимают они в предыдущем поколении технологий. А что делать в связи с необходимостью перейти на новое поколение, спросить не у кого. И отмазка, что ты эти технологии сам еще толком не изучил, не проходит -- изучать что-нибудь можно вечно, уровень изучения всегда будет казаться недостаточным ("я знаю, что ничего не знаю" -- это уже стандартное мировоззрение культурного человека) а изучение в действие автоматически не переходит.
* * *
Очень хочется нарисовать четырехмерную диаграмму, но не понимаю как. Три плана (жизненный цикл как Vee-диаграмма, эволюция и развитие), и все это разворачивающееся во времени. Понятно, что развитие можно показать просто дублированием трехмерной диаграммы ЖЦ+эволюция во времени. Но как показать ЖЦ+эволюцию, мне пока непонятно. Обычно и сам ЖЦ уже сложен до неприличия, а при плановой эволюции его природа меняется.
* * *
Из частной переписки с maksimotstavnov по поводу разметки текста ТЗ для получения формальной модели требований, и того, какова вообще природа ТЗ (или вообще "требований"):ailev:
А) любое ТЗ само по себе плод разработки, и поэтому представляет собой assurance case.
Б) в свою очередь ТЗ представляет собой описание системы на низком уровне детализации (высоком уровне абстракции). Соотношение функционального и конструктивного описания в ТЗ, а также их связи (архитектуры) непонятно.
В) тут еще мутна связь между "пирамидкой" assurance case и "пирамидкой" детализации.
maksimotstavnov:
Все это не формализуется в ближайшие 50 лет IMHO. Но ты хорошие вопросы ставишь.
ailev:
Это я даже не касаюсь неформального текста-описания.
В реальности же тексты описания содержат какую-то дикую смесь А, Б и В, с которой вообще не разобраться. Плюс обильно цитированные (часто без указания источника) положения нормативных актов и стандартов.
И еще сложность от variant management: не поймешь, что в этих ТЗ относится к семейству/серии систем/продуктов, а что к индивидуальным системам.
maksimotstavnov:
Но, кстати, я вообще подозреваю, что от понятия "ТЗ" в связи с "выращиваемыми" или "наращиваемыми" системами придется отказаться. Давно уже только bug reports и feature requests остались.
Чтобы два раза не вставать: ссылки на assurance case -- http://ailev.livejournal.com/578461.html
Когда я вчера писал про "общие курсы" (http://ailev.livejournal.com/625203.html), я этого еще не видел. Но рад -- не ошибся. Ибо знание про собственно tripping (спускоподъемную операцию для заметы бурового долота) специфично, а вот технологии для построения системы управления такими операциями используются везде, они абсолютно неспецифичны.
* * *
На Музыка Москва 2008 так и не пошел. Вместо этого поиграл полчаса на клавишах -- попробовал несколько новых комби (комбинация звуков под управлением Карма), традиционно восхитился. И по поводу похода на эту выставку опять вспомнил любимую свою картинку:
* * *
Ввязался в споры по выбору фотоаппарата для любительской съемки (любительская -- это когда снимаешь уже не случайно, вспомнив о камере в телефоне или завалявшейся в сумочке мыльнице, а намеренно. Но не сильно фанатеешь и не зарабатываешь на этом). Вдруг кому еще интересно: http://ella-p.livejournal.com/847762.html. Суть моей рекомендации: Panasonic G-1, поступающий в продажу как раз в октябре-ноябре -- ибо определяющим параметром являются размеры и вес при малой (4-5, а не 25-35) пиксельной плотности матрицы. Желающие проверить эту рекомендацию -- покопайтесь в базе данных фотоаппаратов на http://www.dpreview.com/ (четвертая строчка меню в правом верхнем углу).
Дискуссия о фотоаппаратах мне очень напоминает дискуссию о фортепианных клавиатурах (всегда находятся как сторонники пальцы ломать об тяжелые деревяшки клавиш, так и сторонники качать бицепс тасканием громоздких и тяжелых камер. Традиции, они и есть традиции. Автомобиль должен повторять формой телегу, так? И вместо руля ему желательно приделывать вожжи -- они ведь "так удобно сидят в руке").
* * *
Самое большое напряжение мысли -- это перевод знания о предмете (всегда неполного!) в план хоть каких нибудь действий. А потом попытки воплотить этот план в реальность. Ибо так легко извинить себя в том, что ничего не понимаешь, и найдутся понимающие люди, которые что-то тебе подскажут -- нужно просто найти их, повстречаться, и все само устроится. Опыт показывает, что находятся люди, но понимают они в предыдущем поколении технологий. А что делать в связи с необходимостью перейти на новое поколение, спросить не у кого. И отмазка, что ты эти технологии сам еще толком не изучил, не проходит -- изучать что-нибудь можно вечно, уровень изучения всегда будет казаться недостаточным ("я знаю, что ничего не знаю" -- это уже стандартное мировоззрение культурного человека) а изучение в действие автоматически не переходит.
* * *
Очень хочется нарисовать четырехмерную диаграмму, но не понимаю как. Три плана (жизненный цикл как Vee-диаграмма, эволюция и развитие), и все это разворачивающееся во времени. Понятно, что развитие можно показать просто дублированием трехмерной диаграммы ЖЦ+эволюция во времени. Но как показать ЖЦ+эволюцию, мне пока непонятно. Обычно и сам ЖЦ уже сложен до неприличия, а при плановой эволюции его природа меняется.
* * *
Из частной переписки с maksimotstavnov по поводу разметки текста ТЗ для получения формальной модели требований, и того, какова вообще природа ТЗ (или вообще "требований"):ailev:
А) любое ТЗ само по себе плод разработки, и поэтому представляет собой assurance case.
Б) в свою очередь ТЗ представляет собой описание системы на низком уровне детализации (высоком уровне абстракции). Соотношение функционального и конструктивного описания в ТЗ, а также их связи (архитектуры) непонятно.
В) тут еще мутна связь между "пирамидкой" assurance case и "пирамидкой" детализации.
maksimotstavnov:
Все это не формализуется в ближайшие 50 лет IMHO. Но ты хорошие вопросы ставишь.
ailev:
Это я даже не касаюсь неформального текста-описания.
В реальности же тексты описания содержат какую-то дикую смесь А, Б и В, с которой вообще не разобраться. Плюс обильно цитированные (часто без указания источника) положения нормативных актов и стандартов.
И еще сложность от variant management: не поймешь, что в этих ТЗ относится к семейству/серии систем/продуктов, а что к индивидуальным системам.
maksimotstavnov:
Но, кстати, я вообще подозреваю, что от понятия "ТЗ" в связи с "выращиваемыми" или "наращиваемыми" системами придется отказаться. Давно уже только bug reports и feature requests остались.
Чтобы два раза не вставать: ссылки на assurance case -- http://ailev.livejournal.com/578461.html