Обсуждение

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

Ну, насколько я понимаю, на рынке есть дырка между программами планирования работ (типа Primavera) и пакетами 3D-дизайна. Эту дырку пытаются закрывать программами поддержки Supply Chain, пристыкованными к пакетам 3D-дизайна, но классический Supply Chain в этой постановке точно не справляется со многими вопросами, которые встают при управлении крупным инжиниринговым проектом -- оценка сроков, планирование кассовых разрывов, управление качеством и т.д. Все имеющиеся решения весьма проприетарны, пакеты закрыты и только Bentley пытается что-то думать-делать на тему открытых стандартов в этой области. Можно было бы в качестве идеи стартапа взять и сделать то же самое, что сделала Alfresco с Documentum: на базе идеи открытого софта и коммерческого его сопровождения разработать распределенную (т.е. умеющую работать в разных организациях) коллаборативную систему порождающего (в этом фишка) 4D-проектирования, интегрированную с (как минимум, голдратовской, если не более развитой из агентских подходов) системой планирования, всю пронизанную открытыми стандартами для стыковки со всякими legacy системами. Цель такой системы -- инструментальная поддержка крупных инжиниринговых проектов, в которых а) этапы (порождающего) проектирования и (модульного) монтажа существенно пересекаются, и б) которые выполняются большим числом поставщиков из разных организаций. Про жизненный цикл и прочие инжиниринговые мантры я сейчас и не говорю. То есть целью является завернуть сущностную инженерную начинку в организационную оболочку -- ибо сейчас такое заворачивание делается на уровне ручного вышивания систем разных поставщиков. Идея тут в том, что определенная инжиниринговая технология влечет за собой вполне определенные организационные решения/возможности, и их можно сформулировать и поддержать софтом. Вопрос, как такой комплекс будет поддерживать конструирование различных сервисов? Мне кажется, что любой сервис -- это тоже такой завод, и его инжиниринг мало отличается от того, что делается при создании "типичного завода". Дальше начинается цветущая сложность -- что включать в решаемые прототипом задачи, а что не включать. Ибо руки загребущие, глаза завидущие, а инвесторских денег все равно нет. :)

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

Наиболее значим там стык пространства и времени -- а именно, то, каким образом происходит монтаж согласно плану-графику. Смонтированные модули (даже не детали) нужно как-то доставить к месту монтажа, разложить это на каких-то местах (каких? есть ли чертежи такой раскладки?), затем в правильном порядке собрать, затем обеспечить пусконаладку. Вот связь этих перемещений в пространстве (4D) и план-графика с управлением буферами и является предметом заботы. Интерфейсы подобного типа все делают легко: тыкаешь в участок графика, а на экране появляется соответственной степени разобранности на тот момент времени 3D-чертеж. И, вроде бы, даже где-то в далекой Японии такие программы видели. А правильно бы было, чтобы такие программы были повсеместно распространены. Мне кажется, что время для этого уже пришло -- но программное обеспечение, как всегда, опаздывает. Вообще, в 4D-парадигме (включая присущее этой парадигме понятие жизненного цикла объекта) визуализация еще плохо разработана. То, что я описал с планом-графиком и чертежами сборки -- это тупой перенос традиционных 2D+3D-интерфейсов в этот 4D-мир. Конечно, в правильной программе должно быть и собственно 4D-в-2D-представление, как на оригинальных презентациях по ISO 15926, а 3D-представление -- как альтернативное. Но совершенно пока непонятно, как эти разные представления будут работать на практике. Пока известно только, что люди с трудом переходят от 2D предыдущего поколения к 3D. Переход в 4D -- это будет еще один шок. Как всегда, все может упереться в людей и их способности к (пере)обучению.

Я и говорю, что главное здесь интерфейс. Однако, пока с прототипами 3D, а тем более 4D, сейчас слабовато. Как провести этап бумажных прототипов? На пластилине? Легко поверить, что такие интерфейсы через несколько лет будут полностью на точ и с полным, а не окошечным погружением. Но тогда управленческий труд станет реально физическим. Что касается этой системы: задачи - функции - структуры - интерфейс, но с пространством групповой работы ( ведь так?). Индивидуальный - не никаких проблем. С групповой надо повозиться.

На CES 2008 Samsung уже показывает 82" телевизор с разрешением 4*HD -- и нужно целиться уже ровно в такие устройства с touch. Групповая работа при этом будет как недистантной, так и дистантной. По-хорошему, на таких экранах будут совсем-совсем другие интерфейсы, нежели привычные сейчас. Ох, как трудно быть молодой шпаной, что сотрет нынешних с лица земли... И думать нужно вперед лет на пять -- и запаса денег иметь как раз на эти пять лет... Но, похоже, направление мыслей правильное. На западе сейчас распространены stand-up meetings, а очень скоро будет stand-up design sessions -- "парное проектирование", как парное программирование в XP...

В трудных проектных ситуациях на помощь приходят различные замещающие практики. В этом проекте трудности в 1) 3D визуализации предметной информации 2) Организации групповой работы. Это кроме мелочей распределения информации и элементов управления между 2D и 3D. Технически визуализация на самом деле не очень сложна, а выбор форм визуализации уже требует анализа пользователя. Для групповой работы сложнее. Скорей всего не получается перенос из реальности в виртуальность. Мне кажется, что такие групповые формы работы пока не используются. Новый инструмент может обеспечить их возможность. Тут надо смотреть на поведение группы. А прототип можно делать в виртуальном пространстве: 1)Экран там можно любой повесить 2)Что угодно на нем представить 3)Аватарами-агентами разыграть сценку реальной работы.

Только уже не touch, а gesture recognition, конечно.

Да, технически, конечно, gesture recognition. Но для пользователя он будет как точ, только касание будет не экрана, а точки пространства с соответствующей реакцией. Хотя может быть и к просто размахиванию руками в воздухе привыкнем. К мышке привыкли. Опыт работы с Wii показывает, что определённая перспектива в этом есть.

А Вы повторили результаты того Ли с Wii? Появился ли прикладной софт, драйвер мыши, например?

Его драйвер позволяет хорошо распознавать три координаты для 4-х источников. Нам как раз для gesture recognition годиться. А программка имитации доски не работает. Проблемы с использованием DirectХ. Отладить конечно можно, но как то доска не очень нужна и поэтому не возились. Сейчас много для Wii разработок возникает. Уже объявили об полном раскрытии их софта.

Существенная трудность -- это сочетание организационной онтологии с инженерной онтологией. В этом и фишка: сейчас они практически не связаны, и их репрезентации идут в разных парадигмах. Переходы между парадигмами "по клику на упоминание", но это не совместная презентация, а именно что "упоминания" (точки клика, а не самодостаточные объекты, которые можно затем уточнять). Так что трудность -- в визуализации двух domain specific languages. Далее вся дискуссия про crosscutting concerns и weaving -- только абсолютно другая дискуссия, нежели в AOP. Групповая работа, еще раз подчеркну -- это два разных случая: удаленная и перед одним экраном. Нельзя просто писать "групповая работа", нужно уточнять, какая именно имеется ввиду. Более того, нужно различать случаи кооперации (асинхрон, workflow, когда работа идет от одних людей к другим, обеспечивается часто groupware) и коллаборацию (синхронная, т.е. одновременная работа группы над одним и тем же множеством объектов с голосовым и текстовым чатом без заранее известного workflow -- всякие blackboard, chat, conference и т.д.). Прототип в виртуальном пространстве -- это просто 3D-мультфильм. Машинима. Хоть и в Second Life, как делают 70% машинима сейчас. Ибо профессиональные пакеты для 3D-мультфиломов недешевы.

1) Конечно, такая визуализации не тривиальная вещь. Еще важно, чтобы она была понятна не только разработчикам, но и пользователям. Значит без метафор не обойтись. С другой стороны набор элементов, из которых выстаивается картинка не очень большой. И очевидно, что без рыбьего глаза не обойтись. 2) Конечно, можно делать поддержку всех четырех видов групповой работы. Но тут реально задача должна быть на "оркестр". Вариант: "делайте вместе" вместо "всегда делал сам" не пройдет. 3) С визуализации - машинимой - проблем нет. Может и SL здесь не лучший вариант - других куча есть. Можно и 3D реал тайм сделать. Это новый жанр, но больно завораживающий.