December 15th, 2009

2021 год

Выполнение метода

Принятие к действию (enactment) метода в предприНятии (endeavour, проект/программа/организация) является существенным концептом современной ситуационной инженерии методов, в которой метод существует на трех уровнях абстракции: метамодель, методология (набор фрагментов и их связей) и конкретное предпринятие.

Чем инструменты ситуационной инженерии методов лучше инструментов управления бизнес-процессами (workflow+business rules) или инструментов управления проектами?
1. Особое внимание уделяется накоплению знаний, в том числе и неформализуемых (guidance). Поэтому в поле внимания и поддержки попадает конструирование процессов/методов из шаблонов, а не "с нуля". Выделению повторноиспользуемых шаблонов уделяется значительное внимание -- в том числе и путем использования шаблонов высокого уровня абстракции (репозиториев методов).
2. Особое внимание используется обучению людей (хелпы, описания продуктов работы и т.д.), "встроенная документация по процессу/проекту".
3. Управление процессами и проектами обычно в разных инструментах, требует разных групп описаний (на PERT не видны продукты, в BPMN трудно со стадиями и контрольными точками -- хотя в свежей версии это может быть, уже и снято, нужно проверить). В любом случае, традиционные инструменты управления процессами/проектами несбалансированы для различных (инженерной, менеджерской, клиентской, организационной) групп описаний.
4. Существенный упор на группы описаний продуктов работы, команды людей и инструментов, а не только группу описаний процесса-проекта: подразумевается модель деятельности, а не только процесса/проекта.
5. Поддерживает постепенное создание метода (emergent process -- https://openair.rgu.ac.uk/bitstream/10059/220/1/Allison+and+Merali+ISTJ+paper+final.pdf).
7. Есть тенденция к объединению достоинств традиционного процессного подхода и ситуационной инженерии методов (например, SPEM+BPMN).
8. Тоже стандартизовано, но поскольку "процесс" рассматривается как шаблон, то выразимы более сложные случаи, нежели в традиционных проектах-процесссах (например, для ISO 24774 http://www.pa.icar.cnr.it/cossentino/AOSETF08/docs/UnisconKeynote.ppt):
Collapse )
Примеры систем, которые как-то учитывают (или не учитывают) дальнейшее исполнение кастомизированного метода (инструмент+репозиторий):

Collapse )
2021 год

Десктоп суперкомпьютеры по500 евро за терафлопс: куда девать такую мощь

Оно, понятно, что это ненастоящий суперкомпьютер (из NVIDIA GTX295), но бельгийцы собрали настольный блок о 12 терафлопсах за 6000 евро, самый мощный десктоп в мире -- http://fastra2.ua.ac.be/ (там и видео есть).

Куда девать такую мощь? Вычислять ненужное! Используется этот десктоп для 3D-томографии костей (повысили на тех же данных разрешение вдвое за счет того, что увеличили вычислительную мощность в восемь раз). Поглядел я на видео в примере, и понял: -- в основном там считаются данные, которые никогда и никому не понадобятся, их никто никогда увидеть не сможет, кроме крошечных кусочков.

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

В САПР была та же самая задача: какая-нибудь подводная лодка с 4млн. деталями не хотела быстро крутиться на экране -- пока Dassault Systemes V6 не придумала вынимать из базы, рендерить (переводить данные в визуальную форму) и дальше уже крутить только то, что на этом экране помещается. Если вся лодка, то на экране крутится лодка -- винтики в ней не крутятся, их все равно не видно. Если вы сделали зум такой, что стали видны винтики, то тогда крутятся только винтики, а лодки уже не видно, и все лишнее из вычислений для отображения изымается.

У веб-разработчиков такой прорыв был с AJAX -- как и в САПР, в революция произошла именно в тот момент, когда Google в своем почтовом интерфейсе стал обмениваться с сервером не целыми страницами, а только теми кусками, которые прямо сейчас нужны. Все необходимые решения в стандартах, серверах и браузерах к тому моменту уже давно (несколько лет как) присутствовали, но нужно было систематически провести эту идеологию в жизнь. И тут же скорости уже имеющихся каналов и производительности уже имеющихся компьютеров стало хватать для более-менее приличной работы, ранее доступной только в варианте толстых клиентов и локальной базы данных.

Точно так и тут. Не нужны алгоритмы, которые восстанавливают всё. Нужны алгоритмы и способы их вызова, которые восстанавливают только то, что можно посмотреть "на лету" -- и с тем разрешением, которое можно разглядеть. Хотя запрограммировать такое будет явно дороже, чем купить 12терафлопс в настольном исполнении -- зато потом можно будет использовать массово, иметь сканеры чуть ли не в телефонах.