SECR-2010 — различия между версиями

Материал из MaksWiki
Перейти к: навигация, поиск
м (→‎Сергей Архипенков (SPM (guild)) Проблемы разработки ПО или проблемы управления? (7))
 
(Массовая правка: замена Категория:Конференции на Категория:SECR)
 
Строка 725: Строка 725:
 
* По сути первичка — в управлении кадрами. И все связано какими-то автоматами, сопоставления ключей нет
 
* По сути первичка — в управлении кадрами. И все связано какими-то автоматами, сопоставления ключей нет
  
−
[[Категория:Конференции]]
+
[[Категория:SECR]]

Текущая версия на 12:38, 24 апреля 2023

Содержание

О конференции в целом и подготовке докладов

Я уже писал о впечатлениях в своем блоге, но повторю это в отчете и добавлю несколько слов.

Начну с конца. На закрытии организаторы себя хвалили за проделанную работу. За то, что пригласили Страуструпа и других зарубежных звезд. А также — за отбор докладов, по их оценкам, уровень докладов на этой конференции — самый высокий, по сравнению с предыдущими. Я на предыдущих не был, поэтому мне хотелось бы услышать мнение тех, кто был на них по этому поводу. Пишите комменты, или расскажите в отчетах. Но, в любом случае, хвалить себя, несмотря на звучавшую на круглом столе критику и именно по отбору докладов — это отрыв от реальности.

Из мелочей — питание действительно было на уровне. А вот WiFi — нет, из 3 поставленных точек реально работала только одна (conf1) и то — со сбоями, и сигнал от нее не везде был.

А еще организаторы сказали (на открытие, по-моему), что было 1200 участников. Как они их посчитали — загадка. Потому что на открытии конференции и на докладе Страуструпа все были в большом зале на 550 мест (как значится в программе). Зал был заполнен плотненько, но все-таки вряд ли существенно больше, чем на половину. На банковской секции — не больше 30-35 человек. В общем, получается человек 300 максимум. Единственное возможное объяснение — на конференции было очень много мероприятий с отдельной регистрацией и оплатой. Если их все сложить, то общее число будет больше, но это просто одного человека несколько раз посчитали. Вот так.

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

Правда, на банковской секции было написано честно и докладчики от участников — отделялись.

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

На конференции во второй день был круглый стол, на котором программный комитет рассказывал, как оценивал доклады и формировал конференцию. Утверждает, что — честно, как описано. Только не все рецензенты реально писали обоснования своих оценок, и не на все доклады вообще находились рецензенты. Формулировал хотелки по докладам. И призывал добровольцев в рецензенты на следующий год. Я, кстати, записался :)

Часть программного комитета четко выдерживает «научность» конференции, и явно это формулировала. Не жестко, но тем не менее по уровню научной статьи — обзор аналогов, позиционирование в отрасли, заключения. В принципе, в научности статьи ничего страшного нет — если бы они это заявили, то почти любому докладу научность в этом объеме придается за час-другой. И в принципе, это делает статью лучше — если за уши не притягивать. Только они не заявили, а вместо этого — выложили требования к оформлению, на которые, говорят, никто не смотрел (что есть плевок докладчикам). А еще научность — это палка о двух концах. В общем-то ее придать можно чему угодно и она совершенно не говорит о качестве доклада. Что я лично и наблюдал. Хотя из зала некоторые участники полагали научность правильным направлением. Кстати, в самом программном комитете по поводу научности единого мнения нет. Николай Пунтиков, который будет руководить комитетом в следующем году, не считает ее правильным направлением развития. Основная идея у них — это неспециализированное общение программистов. Кстати, было предложение одного из импортных участников сделать еще отдельный трек отвергнутых докладов. В общем, замечания, претензии и идеи организаторам были высказаны, будем надеется, что в следующем году будет лучше. Хотя закрытие не показало, что это услышано.

Из практических соображений докладчикам на будущее — пишите abstract конкретный, а не рекламу. Именно по нему идет начальный отбор кто что рецензирует. И вообще, смотрел ли рецензент статью — неизвестно, потому как сам комитет жаловался — многие рецензенты не утруждали себя объяснением отрицательной оценки. А желающие делать действительно научную работу — могут публиковаться в журнале «Программная инженерия», который был анонсирован и который обещают качественно рецензировать :)

Вообще про научность Терехов говорил еще на закрытии — что еще 10 лет назад он в классическом университете пробивал программную инженерию как науку. И рассказывал байку про Кнута, который ему сильно помешал заглавием книги «Искусство программирования», о чем Терехов ему на встрече сказал.

А с другой стороны — качество докладов на банковском дне, где, судя по всему, с количеством заявок были проблемы и потому научность не блюли — было повыше основной конференции. Было некоторое количество крепких практических докладов, в том числе — от внутренних разработчиков (Deutsche, Райффайзенбанк, Renaissance) про реальные проекты.

Классификация докладов

Когда пишешь впечатления от большого количества докладов на конференции, интересно их классифицировать. Самое простое, конечно, по темам, и тут выделяется несколько очевидных групп.

  1. Интересно для моей работы
  2. Интересно для общего развития
  3. Не интересно как узкоспециальное.
  4. Не интересно как поверхностное, или потому что автор плохо владеет темой.

Однако, это — классификация в контексте моего интереса к определенным темам. А вот можно ли классифицировать независимо от этого? Я выделил несколько групп, и дальше попробую уложить в них услышанные доклады.

  1. На примере одного или несколько реальных проектов, рассматривается некоторая общая методология разработки или ведения проектов. Методология излагается в контексте мирового опыта в этом направлении. Наиболее достойная, на мой взгляд категория, в которой сочетаются теория и практика на высоком уровне. Однако, крайне трудная, из-за ограниченного времени доклада и сложности материала, что не позволяет подробно рассмотреть и то и другое.
  2. Доклад о новых практиках и методах и их применении в работе. Методология при этом остается на заднем плане, однако присутствует и адекватна. Упоминается достаточно понятий и ключевых слов, касающихся методологий, чтобы интересующийся смог с ними познакомиться, однако практики представляют собой развитие или комбинации известного и представляют интерес именно в этом качестве.
  3. Доклад о реальных проекты, сделанные по известным методологиям, которым поэтому не уделяется особого внимания. Акцент на особенностях, встретившихся в конкретном проекте, однако на сами методологии имеются адекватные ссылки.
  4. Презентации современных методологий, например, SOA. Методология может быть как новые, так и достаточно известной, во втором случае интересны детали и особенности применения. При этом автор хорошо представляет методологию, а сама методология — зрелая и имеет практики применения. Часто доклады включают описание инструментов, которые, тем не менее, остаются на заднем плане.
  5. Новые идеи, проверенные на адекватных модельных задачах. Задача обычно небольшая, и от промышленного внедрения идея обычно отделена трудностями, осознаваемыми или не осознаваемыми автором, но в целом доклад достаточно честный.
  6. Доклад о реальных проектах и практиках, при этом методологией автор не владеет: или не представляет современный уровень, или понимает неверно и путается в нем, или просто написал потому как положено. В общем-то для всех было бы лучше, если бы докладчик не ассоциировал свои практики с методологией, а просто их излагал.
  7. Презентации современных инструментов. Обычно — от вендоров, их производящих или внедряющих. Инструменты обычно поддерживают определенные методологии и по аннотации и названию часто можно подумать, будто речь пойдет именно о методологиях, тогда получается обман ожиданий.
  8. Большая методология в общем виде развернута над маленькой задачей. Большая методология в общем виде развернута над не адекватной ей практикой. То есть либо практика не соответствует теории, но это скрывается, либо реально сделанная задача не может служить основанием для таких обобщений. В общем, доклад — надувание щек вокруг крутизны этой методологии, которая часто излагается в общем виде, со сложными формулами.

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

Естественно, доклад должен быть достаточно хорошо структурирован и изложен. После названия доклада — моя оценка по 10-бальной шкале (сначала я пытался использовать пятибальную, но мне психологически некомфортно ставить 2 и, особенно, 1, а без них — остается слишком мало баллов.

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

Новые методологии на реальных проектах

Итак, первая группа с наиболее ценными докладами — теми, где развивается методология как обобщение опыта реальных проектов.

Максим Цепков (CustIS) Учет ценных бумаг — сделать сложное простым

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

Я не буду здесь воспроизводить доклад, презентация выложена на slideshare, а статья вот Учет ценных бумаг - сделать сложное простым (Цепков на SECR-2010).

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

Мина Бустром (SunGard Front Arena) Case Study на примере организации, работающей по Agile (9)

Замечательный доклад по-английски о реальном проекте интеграции, в ходе которого методология Model Driven Architecture, изначально ориентированная на разработку в рамках водопадной модели, была преобразована исходя из принципов Agile-программирования и как результат получена прагматичная версия Model Driven Development в рамках конкретного проекта. «Light agile principles + complex MDA approach = own pragmatic MDD approach!» В докладе очень большая методологическая часть, и это не результат ретроспективного осмысления, они так строили процесс — я после доклада об этом отдельно спрашивал.

Сам проект — реинжиниринг сложившихся информационных потоков между зоопарком корпоративных приложений. Использовался некоторый внутренний протокол tnp, частично описанный, а частично специфицированный в заголовочных C+±файлах с комментариями, причем описания местами не соответствовали реализации. Руководство не хотело большого проекта реинжиниринга и особо не инвестировало, в организации был отрицательный опыт применения классического MDA, а у них самих опыта больших интеграционных проектов не было. При этом C++ реализация сдерживала развитие интеграции, что-то там стрельнуло с размером для типов данных. Так что с точки зрения программистов реинжиниринг был необходим, но полноценный водопад запустить они не могли. Плюс, они уже некоторое время работали по agile-методологиям и верили в это.

В целом за 6 месяцев они задачу успешно решили. Сначала выбрали общую архитектуру и инструменты. Обмен — через XML-форматы с XSLT-преобразованиями как общеизвестную платформу, решили не использовать тяжелых фреймворков и средств моделирования, включая UML, потребовали совпадения логической и физической модели. А дальше — ели слона по частям. Выделяли некоторый фрагмент информационных потоков, в рамках спринта проводили анализ и reverse engeneering из кодов для восстановления модели данных и реализовывали основной сценарий, в следующих спринтах — наращивали подробности и особые случаи, потом переключались на следующий фрагмент. Для reverse engeneering сделали собственный инструмент.

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

Доклад примечателен не технологическими решениями интеграции, а построением конкретного проекта исходя из принципов agile, с адекватной адаптацией тяжелой методологии, рассчитанной на водопад. Что касается технологий, то есть известный мультик, как страуса учат летать с лозунгом «лучше два часа учиться и за десять минут долететь». Они — не летели, они бежали и добежали. И мне лично очень хотелось бы увидеть презентацию или статью — формулировки на слайдах меня впечатлили.

Радован Вреска (DandiWay s.r.o.) Конфигурационно-ориентированное программирование (7)

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

В докладе этот подход был назван конфигурационно-ориентированным и рассматривался как следующая стадия развития программирования в целом, которую докладчик видел таким образом:

  1. императивное
  2. структурное и процедурное
  3. объектно-ориентированное
  4. конфигурационно-ориентированное.

В отличие от ООП, в центр концепции ставится не просто тип объектов, экземпляры которых можно рассматривать как однородные, а настроенные, сконфигурированные экземпляры объектов. Эти настроенные объекты естественно можно рассматривать как вечные. А для поведения конфигурация объекта часто важнее, нежели его тип. И система в целом представляется как совокупность гармонично настроенных объектов, ее собирают как композицию как рисунок (человека) собирают из частей (кружочков и линий).

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

Новые практики и методы работы в реальных проектах

Доклад о новых практиках и методах и их применении в работе. Современная методология автору известна, присутствует и адекватна, при этом остается на заднем плане. Предлагаемые практики местами ее опережают или являются неожиданной комбинацией, которая методологически не осмыслена. Как и mainstream современного течения по организации проектов — agile методологии, которые прежде всего — наборы практик.

Стас Фомин (CUSTIS) Agile Learning: Эффективные инструменты (10)

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

А если серьезно — то это презентация инструментов работы со знаниями, которые используются у нас в компании и активно развиваются и пропагандируются Стасом. Инструменты — на базу MediaWiki с многочисленными расширениями, создающими многоцелевое информационное пространство — с презентациями, блогами, тестами, опросами, календарем, личными заметками-закладками, разнообразными визуальными представлениями. Важно — что в едином инструменте и полностью открытое, это большой плюс.

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

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

Насколько получилось это донести и инициировать активность в слушателях — посмотрим. Все-таки, это сложная задача. Во всяком случае, есть общедоступный http://wikisandbox.custis.ru, сделанный Стасом специально для того, чтобы каждый мог попробовать этим пользоваться. А сами инструменты являются общедоступными и бесплатными. Стас распространяет установленную у нас конфигурацию для быстрого старта, обещает выложить в open source, но пока не успевает.


Александр Орлов (Happy-PM.com) Трудности перехода в менеджеры в разных типах ИТ компаний (8)

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

Сильно нового лично я не услышал, поле информации знакомое — и из общения вокруг, и из книг (у Йордана в «Смертельном марше» много есть, и не только у него). Но, все равно, доклад — интересен.

Иван Падабед (EPAM Systems) Архитектура в мире SharePoint (7)

Полное название доклада: «Управление жизненным циклом архитектуры в мире SharePoint». При этом доклад — практика, излагался собственный опыт, рекомендации, сложившиеся в ходе работы над проектами.

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

Дальше — некоторый набор тезисов, который я зафиксировал в процессе доклада. Если Вы хотите использовать Sharepoint, но не являетесь в нем профессионалом, то лучше, конечно добыть саму презентацию и, возможно, получить от профессионала комментарий. Ценность тут не только в рекомендациях, но и в обозначенном круге вопросов. Сам я профессионалом не являюсь, хотя в паре Васей Кудрявцевым, который профессионал, мы тут сделали успешный пилот, одобренный кураторами от MS и заказчиком. Так что комментировать не буду.

Уровни приложения:

  • sharepoint level
  • domain logic layer — создается по необходимости, сборки
  • data access — тоже необязателен, но нужен при интеграции с разнородными источниками данных, service locator в репозитории
  • domain entities — автоматическая генерация spmetal, расширяется за счет partial class.
  • common service layer — хелперы и т. п.

Как внедрить архитектуру в проект

  • заказчику архитектуру продаем, слайды с диаграммами и т. п.
  • бизнес-аналитику надо заранее объяснить узкие места и архитектуру вообще, а если аналитик=архитектор, то не надо
  • команде разработки — объяснить принципы, и их обязательно надо убедить, а то они по-своему делать будут, и нужно не только объяснить, сложные места сделать прототип и показать, чтобы не слова
  • полезный документ — reference implementation (набор полезных практик)
  • внедрение архитектуры — architect guidance — допущения, ограничения, особенности платформы; его надо поддерживать актуальным
  • важно, забывают — развертывание, обновление (2 версия), копирование/восстановление.
  • нужен контроль исполнения — code review и architect review, их надо сделать частью процесса!
  • ну и документация: делайте диаграммы — полезно (достаточно MSVC2010U), обновляйте доки.

В архитектуре важно повторное использование

  • общий код, общие компоненты — в целом понятно
  • управляемые метаданные,
  • workflow activities — есть большой класс проектов, где это тиражируется
  • архитектура тоже повторно используется, для этого надо фиксировать — reference implementation (набор полезных практик), architect guide, patterns

Гарантий хорошей архитектуры нет, одинаковых проектов тоже, но есть похожие, и надо отлавливать хорошие практики и их использовать. Не только самим, но чтобы весь проект это делал. И важность архитектуры — доносить до заказчика.

И несколько слов о том, зачем, по его опыту, используют SharePoint:

  • Интеграция
  • Заказчики поменьше или большие но жадные, которые хотят получить что-нибудь быстро. Но ему не нравится потому что не расширяемо
  • Бывает просто хотят обернуть какую-нибудь свое приложение

Внутри они sharepoint используют не слишком, но все идет к тому, чтобы все поделки засунуть в общий портал.

В целом вполне содержательный доклад. И не думаю, что очевидный, разве что с позиций «я и сам крут».

Вадим Вейбер и другие (ТПУ) Интеграция приложений нефтегазового предприятия (6)

Полный состав авторов и название — Вадим Вейбер, Антон Кудинов, Николай Марков (ТПУ), «Использование метамодели предметной области для интеграции информационных систем и приложений нефтегазового предприятия». Докладчик связан с Томским университетом и фирмой, автоматизирующей нефтегазовые предприятия.

Информационная система предприятия — трехуровневая ERP — MES — SCADA.

На нижнем уровне, SCADA — системы реального времени, контроль технологического оборудования. И там — полный зоопарк от разных производителей, связанных с железом (скважины и прочее). MES — контроль выпуска, производственные операции. Стоит их собственная система, и пара систем сбоку — модели трубопроводов и геология. Что используется в качестве ERP — не прозвучало (может, тоже их система).

Задача интеграции — обеспечить передачу технологических данных от SCADA к MES, обмен систем среднего уровня между собой и передачу в ERP. Вместо связи «каждый-с каждым» делают метамодель и кладут все туда более-менее однородно. Чтобы не разрабатывать метамодель с нуля, используют стандарт нефтегазовой области. Взяли PRODML, он международный, и зарубежный зоопарк про него нечто знает. Но не все. Описывается иерархичная структура описания объектов предприятия и логистику — поток продуктов, product volume report. Стандартного описания не хватает из-за специфике предприятия и они его расширяют.

Что касается платформы интеграции, то стандартных они не использовали, сделали свою. Для каждого приложение сделан адаптер для преобразования, работающий как web-сервис, и самым сложным была разработка этих адаптеров. Адаптер читает данные, выдавая поток или, наоборот, кладет данные. Реализовали для этого некоторый product flow model builder и шаблон адаптеров.

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

Почему не использовали что-то стандартное — стандартная отмазка, что специализированное лучше. Хотя не факт, что они что-то нашли бы. Они называют свою реализацию интеграцией PRODML с SOA, хотя с моей точки зрения SOA тут присутствует лишь как омоним для service.

В вопросах был флейм в научную сторону — в чем научная новизна, нельзя ли было сделать мат.модель предметной области чтобы правильно расширить PRODML. Автор плавал, это минус, но, с другой стороны, страшно далеки спрашивающие от практики… А в чем преимущество со стандартными монстрами интеграции — автор не знает, но уверен, что они есть.

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

Владимир Ковалевский — Адаптация методологии SCRUM к существующим бизнес-процессам компании (5)

Энергичный доклад, но без систематизации, некоторая смесь из собственного опыта. А предмет — внедрение Scrum от менеджера-евангелиста, который хочет таким образом улучшить ситуацию. В принципе, достаточно распространенный сейчас кейс. Ну и рассказывал — что получилось, заметки с полей, так сказать. В них есть интересные моменты. Мне нравятся такие доклады — потому что докладчик увлечен и верит, а недостатки спектра представлений — пройдут с опытом. Если, конечно, докладчик и дальше будет менеджером, а не станет тренером.

Далее — заметки.

  • Почему сдвигаются сроки при планировании в диаграммах Гантта. Понятно почему — всякие флуктуации и взаимосвязи, и все ползет.
  • Много проектов — один разработчик: задачи в спринте тагировали, и шла смесь по совокупности проектов.
  • Важно, чтобы все (аналитики, разработчики) работали в едином ритме
  • Идея — конструктор Лего: фреймворк. Нельзя абстрагировать все. Чтобы не копировать код, чтобы задачи были типовыми. Технически унификация — хорошо, но психологически и организационно — тяжело.
  • Насаживать SCRUM — плохо, будет отторжение. Я: какой-то тут менеджерский скрам…
  • Постепенное внедрение
    • Сначала план не вообще, а двухнедельный
    • Потом часы начать писать
    • И так далее…
  • Гантт — не дает оперативную картину, используют долгосрочно, а SCRUM — текущее управление.
  • Стоимость — обоими способами, по классике и через планинг-покер
  • Ошибки:
    • хотелки не вбрасывать в спринт
    • надо фокусироваться на главном
    • планировать тщательно и долго (8-9 часов)
    • не гнаться за учетом ресурсов
    • сложность и важность — матрица
    • скрам-мастеру рассказать о роли

Олег Ридченко (Intetics Co.) Mind the Gap — что делать с растущими ожиданиями клиента (8)

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

Итак, тезисы.

  • Ожидания возрастают и это объективно, такова психология — значит надо поддерживать ценность.
  • Ценность — субъективна! Это восприятие того, что команда приносит клиенту.
  • Пагубное заблуждение — что клиент должен сам оценить, что команда работает хорошо. Не оценит, потому что нет времени на анализ и недостаточная компетентность в технологической области, и он может не понимать, почему то, что для него сделано = технологически трудно, это надо объяснять, технологии — они от него скрыты в продукте.
  • Очень важно строить канал позитива, а не только канал разбора негативных ситуаций и это — ваша инициатива.
  • Распознавание ценности (в бизнес-смысле, для клиента), описание и оценка, донесение, корректировка.
  • Вопрос — что ценного мы сделали ему в течении последнего месяца, задавать себе регулярно
  • Это должен делать не только руководитель проекта, но и вся команда.
  • Если команда работает в этой парадигме, то она дополнительно может:
    • выявлять противоречия в спецификациях
    • обосновывать клиенту технические решения
    • делать проактивные предложения
    • оценивать свои достижения с позиции клиента
    • членов команды можно показывать клиенту, он их запоминает
    • возникают тесные и прочные отношения
  • Ценность надо доносить в измеримых величинах (цифрах, а не просто «лучше»). Да, абсолютная объективность — недостижима, много зависимостей. Но надо пытаться (здесь был пример, что можно, но — примитивный)
  • Из общего — не быть скромным! а то «все так делают» и т. п.
  • Подача: европейцы +20, американцы +40, наши — скромничают −20. Аудитория — она знает типичное приукрашивание, и автоматом отнимают сколько принято (без учета страны заказчика).
  • Итого — надо корректировать динамику, чтобы не проваливалось ниже ожиданий.
  • А еще — если улучшать донесение ценностей — возрастает и фактическая польза. потому что каждый член команды соотносит свою деятельность с тем, что нужно клиенту.
  • Стоит регистрировать в электронном виде. Минимум — description, value gains (измеримые), кто. Но задача регулярного заполнения такой формы — не простая. Так что начинать — не стоит…

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

Ответ: Не надо клиенту сразу делать ОЧЕНЬ хорошо — чтобы не росли ожидания чересчур быстро.

Вопрос про качество. Нельзя накладывать бенчмарк на инженера — потому что инженер тут же придумывает, как бенчмарк достичь, но результат реальный достигнут не будет. Предложенный подход — хорошо. Потому что устранение багов, повышение качества — тоже ценность для клиента.

Вопрос — измерения и конкуренция, хорошо ли это. Ответ — здоровая конкуренция — хорошо, если конструктивно и надо поощрять.

А еще это стоит переносить и внутри компании. Хороший пример — сисадмины в ИТ.

Сергей Архипенков (SPM (guild)) Проблемы разработки ПО или проблемы управления? (7)

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

Но есть нюанс. Вместо треугольника предлагается 4П — продукт, персонал, процесс, ПМ (project manager) и рассказ начинается с того, что надо брать проекты с 500 % прибыли. Понятно. что с такими продуктами можно об остальном не слишком думать. Ну и в целом изложению на мой взгляд, не хватало систематичности, был некоторый набор фрагментов вместо мозаики.

Запомнилось: «Есть мнение, что программисты — антибюрократичны. На самом деле они — анти-идиотичны и не делают то, смысл чего не понимают». Зал к явным нападкам на священные коровы относился плохо, в конце — попытался подавить каким-то американским опытом, впрочем очень косноязычно изложенным.

Далее — заметки.

  • миф о треугольнике: сроки-функционал-качество
    • пример MS Word — сроки и бюджет превышены в 5 раз
    • теория -W барри боэма
    • надо ориентироваться не на треугольник, а на людей.
    • каждый должен выиграть! программисты — написать, заказчик — получить и т. п.
  • 4П: продукт персонал процесс ПМ (project manager)
    • продукт — который 500 %, а не 10 % прибыли
    • персонал — хорошие программисты.
    • Маслоу «Новые рубежи человеческой природы». Маслоу отказался от своей иерархической пирамиды, оставил 2 типа: дефицитарные (их надо до 80 %) и экзистенц, самореализация
    • программисты — не антибюрократичны, они антиидиотиичны и не делают то, смысл чего не понимают
    • процесс — адекватен продукту. продукты разные и процессы — тоже разные. Не максимум эффективности в моменте, а максимум на интервале времени. Долой массовые сверхурочные и т. п.
    • ПМ: эффективность участников (1) и эффективность коммуникации (2)

Вопрос из зала — противоречие тенденций. Американцы (кто?) хотят зафиксировать потребности. Но есть спектр, звезды в 28 раз лучше, однако звезд мало, а когда выбираем не звезд — надо компетенции. Я: это некоторый сумбурный бред.

Илья Сегалович (Yandex) Опыт разработки в Яндексе: особенности процесса и ключевые технологии (9)

Илья рассказывал о реальном устройстве процессов в Яндексе. Говорил очень быстро и насыщенно, уложился в тайминг. Но хотелось бы больше подробностей, и, главное, больше концепций. Хотя часть концепций он достаточно хорошо проговаривал. в том числе — управление верхнего уровня (миссия, стратегия и так далее), мотивация и премии. Так что это из серии «хорошо, но можно лучше».

Что запомнилось и впечатлило:

  • активная внутренняя жизнь, публичность отделов и разработчиков, внутреннее общение
  • выступление на конференции, в том числе внешняя — бонус для разработчика

Если сопоставлять с тем, что у нас — много похожего. Хотя местами играют масштабы. А посмотреть и перенять опыт — оно полезно.

Далее — тезисы, пересказывать нет особого смысла.

  • разработка: сервисы и проекты. Проект — ограничен по времени
  • программисты:
    • руководитель и эксперт-разработчик на одном уровне
    • менеджер и разработчик — на одном уровне иерархии, равны.
    • гуманизм как принцип работы
    • недостаток — менеджеру надо зарабатывать карму, нет авторитета должности
  • премия:
    • до 2008 — квартальная, на отзывах, коэф.перформанса
    • сейчас — раз в месяц конкурс достижений, руководители — выдвигают, есть комитет принимающий решения
    • премируются команды, дальше распределяют
    • оценивается, в основном — то что наружу
    • опционы правда не слишком понятно для непубличной компании
    • конференции — статьи — зарубежные школы
  • Поиск талантов — университет, стажеры, практиканты (учебные проекты)
  • Инструменты и регламенты — есть, иногда жестко на уровне команды или сервиса, как самоорганизация. Есть код ревью, есть области, недоступные коммиту начианющих
  • Регламенты уровня компании
    • миссия яндекса — давать ответ
    • устав нашего монастыря
    • стратегия — ежегодно. это хороший дорогой документ
    • процедурные регламенты: чеклист запуска проекта, увольнения, устав менеджера
  • Квартальные презентации, квартальное планирование
    • планирование — вики.
    • жира, контроль версий, и прочее
  • технологии — описаны. 130 докладов опубликовано + субботники 63 + YaC…
  • технологии
    • технология matrixnet современная высокая технология, внедряют по всей компании
    • их версия MapReduce
    • яндекс-пробки
  • Вопрос про увольнения — пока не регламентировано, стараются чтобы сотрудник знал о проблемах, но получается не всегда, регламентами не поддержано
  • Тестирование — две команды — в Питере тестеры и в Москве нагрузочные тесты, они не входят в подразделения, все проекты проходят через них.
  • Не все сервисы приносят деньги. Но в стратегии — прописано зачем какие сервисы делают, какие цели. Туда надо попадать.
  • Статья — как производительность зависит от устройства компании. Очень повышает производительность общий кафетерий.
  • Генерация идей — не проблема, идей у них много. Проблема в реализации, планировании
  • В вопросах была идея — дайте выключить магазины в результатах поиска, даже готовы заплатить
  • С пользователями — служба с 99 года ежемесячные сводки и прочее. Пытаются и снаружи, как google.

Реальные проекты по известным методологиям

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

Михаил Сенаторов (Центробанк) Разработка и сопровождение программного обеспечения (4)

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

Из содержательного.

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


Андрей Калмыков (Deutsche Bank) От Time and Materials к Fixed Price (7)

Полное название доклада — Актуальные проблемы перевода аутсорсинга разработки ПО с модели Time&Materials на Fixed Price. Реально любопытный доклад о практиках организации разработки в Deutsche Bank. Докладчик — из московского центра разработки, у банка — несколько таких центров по всему миру, и московский сейчас по факту — самый крупный. Особенность организации разработки — преимущественная ориентация на крупных вендоров, являющихся стратегическими партнерами банка. Исторически вся разработка строилась на основе Time and Materials, а переход вызван не столько экономией (это на заднем плане), сколько желанием взять под контроль и предоставить бизнесу информацию о реальной стоимости и сроках тех или иных доработок для принятия решений на старте разработки, а не по факту. По опыту — узнав стоимость или сроки отдельных доработок бизнес просто начал от них отказываться, предпочитая сохранить нынешний уровень. Плюс, предварительная оценка дает возможность организовать тендер между вендорами в тех случаях, когда альтернативы имеются.

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

Еще они хотят, чтобы центру разработки было предоставлено право самим выбирать, кто будет разрабатывать — собственные разработчики банка, из какого центра разработки, или конкретные вендоры. Сейчас это часто спускают сверху. О размещении разработки в России или Индии он сказал, что в тех местах, где нужны мозги, а не тупое тиражирование готовых решений, разработку в Индию выносить нельзя — там просто не справятся. И тестирование — тоже выносить нельзя, потому что тестирование их продуктов тоже требует творчества. А вот вынос сопровождения уже разработанных продуктов в Индию — вполне реально, если обеспечить нужный уровень документации по проекту. И уже есть успешные примеры. Я: Правда, по моей информации от знакомых это не так — политика найма и оплаты персонала банком в Индии такова, что на поддержку попадают люди без необходимого уровня знаний (например, что есть такой протокол TCP/IP), а как только они получают их в процессе работы — они тут же уходят в другие компании на менеджерские должности.

Таисия Сигбатулина (Райффайзенбанк) Управление требованиями к производительности (5)

Полное название доклада: «Управление требованиями к производительности при внедрении новой информационной системы», а у Таисии был еще содокладчик — Владимир Кувшинов из HP. Который в той части доклада, которую я слушал — преимущественно молчал, а если рассказывал — то про средства HP-платформы, на которых все было поднято или может быть поднято.

А Таисия рассказывала про всякого рада нагрузочное тестирование, как при приеме нового продукта, так и для новых версий существующего. Проблема у них в том, чтобы собрать качественные требования на систему по производительности, отличающиеся от встречающихся сплошь и рядом формулировок «любой отчет должен создаваться за 2 минуты» или «любая форма должна открываться за 10 секунд». Они идут через анкеты пользователей, пытаются выявить бизнес-ситуации, которые потом превращают сценарии. Плюс — анализируют логи существующих систем, выявляя операции оттуда, хотя сама она считает, что анкетирование пользователей — надежнее. А дальше для каждой версии — сценарии выполняют. Еще были отдельные рассказы про калибровку — чтобы по тестированию в тестовом окружении делать заключение о том, что будет на промышленном сервере.

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

Алексей Сприжицкий (Deutsche Bank Moscow) Платформа для алгоритмической торговли (6)

Полное название доклада — «Глобальная платформа для алгоритмической торговли: архитектура и технологии». Рассказ был про конкретную систему биржевой торговле и архитектурные решения в ней, обеспечивающие высокую параллельность обработки на всех уровнях (которые tier), в сочетании с требованиями конкурентности.

Начинается от технических решений. Таких как пулы параллельно работающих серверов, на которые перенаправляются запросы, если запросы потенциально независимые. При этом маршрутизатор тоже должен быть дублирован, и не только для баланса нагрузки, но и для резервирования. Что бывает при конкуренции — пулы серверов, которые делят обработку по видам конкурентных ресурсов, например, по инструментам. Плюс зависимость на очередях: все запросы одного клиента должен обрабатывать один сервер. То есть типовое решение — параллельные запросы выстраиваются в линейную очередь, откуда разбираются конкурентными серверами с учетом зависимостей по запросам. Поток данных в отчеты — через чтение теми лога изменений (transaction log).

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

Решение — их собственное, они смотрели вендорские решения, но все не потянули по нагрузке. У них сейчас нагрузка 30 млн заявок в день, обработка заявки 300 микросекунд (0.3 миллисекунды!) с учетом сети, хотят еще в 3 раза ускорить. Вендоры меньше 1 миллисекунды не дают.

Илья Поздняков (Renaissance Capital) Построение хранилища данных (6)

Полное название доклада: «Специфика построения хранилища данных в инвестиционном банковском бизнесе», а реально это была success story о том, как за полгода сделали хранилище в банке и загрузили в него данные, включая историю, и какие проблемы при этом решили.

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

В целом рассказ — понравился.

Владимир Рубанов, Андрей Пономаренко (ИСП РАН) Генерация тестов (6)

Полное название доклада: Автоматическая генерация базовых тестов для программных интерфейсов.

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

Они его написали. Он работает по заголовкам функций (на C++), при необходимости применяется псевдоразметка — если в функции передаются объекты, то их может быть нужно конструировать достаточно корректно, могут быть ограничения на допустимые значения аргументов. В принципе автогенерация работает, даже если ничего дополнительно не описывать. Генерация идет в свой фреймворк запуска тестов и несколько стандартных — q2c и еще какой-то, связанный с opengroup.

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

Все это опубликовано http://ispras.linux-foundation.org/index.php/API_Sanity_Autotest, сторонние тоже разработчики используют, чтобы сделать формальное покрытие поверх фрагментарных тестов, написанных вручную.

Было много вопросов про качество получающегося покрытия тестами. Ответов несколько. Во-первых, такие тесты — лучше чем их отсутствие вообще, и они выявляли ошибки. Во-вторых, технология использовалась для уважаемых заказчиков и результат тех удовлетворяет. Они много сотрудничают с nokia linux и, в частности именно так были официально протестированы . В принципе, все эти библиотеки были сделаны до того, как лейбл о покрытии тестами стал столь важен, и работают в реальных проектах. Так что заказчик во многом хотел повесить лейбл. Ну и какие-то ошибки тоже нашли.

Были идеи о том, что можно вызвать каждую функцию не один раз, а несколько, варьируя комбинации параметров, например, если целое — то случайное целое и большое на границе диапазона. Докладчик сказал, что в принципе можно, но нужна доработка. Вообще это у них третий фреймворк по тестам, начинали они с глубокого тестирования, но это очень трудоемко и заказчикам, как правило, не нужно. Им надо повесить лейбл о 100 % покрытии (это уже я домысливаю, докладчик не говорил).

Наталия Свиридова, Андрей Калиничев (Diasoft) Diasoft FA# (5)

Полное название доклада: «От „клиент-сервер“ к SOA. Эволюция АБС на примере Diasoft FA#».

Доклад был о том, как Diasoft 5NT(?) переводили на SOA, превращая в Diasoft FA#. При этом методология тоже приобрела некоторые причудливую интерпретацию. А стиль доклада success story разработчиков о том, как они долго и упорно строили красивое здание…

Предыстория была о том, как они поделили единое решение на модули. Без архитектуры, руководство поставило задачу и провило границы просто по бизнесу, разработчики исполнили как получилось. А получилось 4000 процедур межмодульного API, по сути остался тот же монолит, поскольку границы — витиеваты. И это — FA# 7.1.

А дальше, в 2008 — на это уже начали смотреть архитекторы и аналитики, проектировать «правильное» API, имеющее бизнес-смысл, убирать дублирование. В результате «созданы тысячи новых процедур на замену старых». И, собственно, то что получится — это уже SOA, потому как сервисы получаются. Это FA# 7.2, 30.11.09. А дальше — идет перевод на JavaEE и это обеспечивает постепенную замену модулей. Итого проекту 5 лет.

Примеры API в цифрах:

  • Главная книга — 300 методов, включая справочник клиентов
  • РКО — тоже 250—300 методов.
  • остальное — поменьше, но реально потому, что внешнего управления просто не предусмотрено, работа с интерфейсов.

На все API есть документация, поддерживается совместимость.

Что это дало? Производительность за счет кластеризации, монолит можно пытаться разносить.

Презентации современных методологий

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

Сергей Шелягин (CQG) Технологии — основной фактор развития срочного рынка (4)

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

Леонид Феликсон (SOA Systems) Манифест СOA: Достижение общего понимания СOA и сервис-ориентации (6)

Возможно, я слушал не совсем этот доклад — этот на основных днях, а я слушал Феликсона на банковском дне вместо заявленного в программе доклада Томаса Ерла. Да, аббревиатура «СOA» — из официальной программы конференции. Забавно смотрится. Сам доклад — вполне профессиональное и детальное изложение SOA-манифеста и целей, которые хотелось бы достигнуть. Целей тут две, и обе направлены на поворот сознания.

Первая цель — собственно интеграция. «Теперь программисты не стремятся писать код, кроме некоторых испытывающих от этого кайф. Вместо этого они берут готовый код и комбинируют его для получения нужного функционала. И идея SOA — в том, чтобы было легко это сделать.» Это пересказ, а не цитата, но смысл передан. У меня это вызвало ассоциации с идеей постиндустриального общества, в котором реальное производство переносится в Китай и другие подобные страны, а в развитых — остаются услуги. Лично я к этой идее отношусь скептически, как в рамках общества в целом, так и в рамках программирования в частности. И таки примеры, как google, приводимые сторонниками, меня не убеждают, но, тем не менее, вопросы интеграции и комбинации готовых продуктов — они достаточно актуальны, а многие программисты и вендоры оставляют их на заднем плане при продумывании и реализации своих продуктов. Лозунг обращен к ним и призван повернуть сознание. Правда, серебряной пули тут нет, и как инструмент SOA не сильно отличается от других архитектур и подходов, которых было множество. А хорошо интегрированных систем все-таки не получается. Наверное, задача сложнее и одного лозунга тут недостаточно :)

Вторая цель — бизнесово-продажная. Бренд SOA по мысли авторов призван облегчить программистам общение с бизнесом, передачу им своих идей. Интеграция, обмен сообщениями, репликации — это какие-то технические термины, бизнесу они не нужны. А вот service — это бизнес понимает. Вот и предлагается описать систему через сервисы, как бы на понятном бизнесу языке :) В общем, то достаточно наивно. При этом было явным текстом было сказано, что SOA — просто бренд. Никаких новых подходов или нового кода за этим нет — зачем, все уже придумано. код написан, надо лишь комбинировать :)

Лично я, в общем-то, знал, что SOA — просто бренд. Но вот идеология вокруг этого, обесценивающая разработку как таковую — она меня огорчила, да. По-моему, это — отрыв от реальности. А еще я осознал для себя, что SOA не связан с объектно-ориентированным подходом, они находятся в разных плоскостях и сервис, в общем случае, объектом не является. Это, скорее, просто некоторый набор процедур.

Спенсер Грин (TIBCO) Можно ли было предотвратить падение рынка 6 мая? (3)

Полное название доклада: «Можно ли было предотвратить падение рынка 6 мая и что делать, что бы избежать подобного в будущем?»

В общем-то тема — дань конъюнктуре. Для тех, кто не в курсе — 6 мая 2010 года произошло резкое катастрофическое падение рынка в течении нескольких секунд, судя по всему потому, что на рынках торгуют роботы, и они одинаково среагировали на некоторое движение, и дальше — по принципу домино. Соответственно, пока люди среагировали — было поздно. С точки зрения электронных торгов — в систему не был встроен предохранитель, останавливающий торги или его быстродействие просто никто не удосужился проверить. С точки зрения макроэкономики — рынок в условиях кризиса неустойчив, и это известная проблема у которой пока нет решения.

Но всего этого в докладе — не было. А были — методологические рассуждения про смену парадигмы IT для подобных приложений. Которые становятся event-based и real-time — они должны среагировать на событие, и скорость реакции имеет не меньшее значение, чем качество решения. К сожалению, решений что делать — в докладе не было (я не услышал), только общие рассуждения вокруг. Может, не дослушал…

Джордж Шарков (ESI) Разработка ПО: от исследований к бизнесу (5)

Доклад по-английски. На философскую тему, что такое разработка — исследование (research) или бизнес. И основной проблеме, с этим связанной — не гарантированном результате и рисках из этого следующих. Со сравнением с другими отраслями, например, созданием бытовой техники, которое тоже исследование местами. Идея в том, что создание технологий — это действительно исследование, а вот их претворение в практику (adoption to production) — это уже бизнес. Эти стадии надо четко различать, формулировать бизнесу. И надо учиться доводить технологические идеи до практики как гарантированный бизнес-процесс.

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

Бен Лившитц (MS Research) Современные веб-браузеры (5)

Полное название доклада — Современные веб-браузеры и роль исследований реальных систем. Доклад был про возможности броузеров, которые в процессе просмотра сайтов запоминают интересы пользователей, а потом это используется при представлении ему информации, контент страниц и реклама адаптируется в соответствии с запомнеными параметрами. При этом эта информация складывается централизованна, если пользователь участвует во всяких социальных сетях и прочих конструкциях и устанавливает всякие фенечки от них. В броузерах есть инструменты сбора логирования через jscript, а сайты пишут с динамической заменой — replay для уменьшения времени отклика. Либо она может накапливаться на стороне броузера в разных куки, которые используются многими сайтами, держатели сайтов кооперируются для этого. Были ключевые слова по технологиям, но я не уверен, что правильно записал — netflex, repriv. Есть базовый базовый уровень информации, иерархия интересов, но далее ее можно расширять как внутри, так и вне броузера. Шаги безопасности теоретически не отменяются.

Понятно, что такие сайты сильно грузят броузеры, особенно с учетом безопасности. И современные броузеры вынуждены прогибаться. Было сравнение разных броузеров по разным метрикам, показывающее различия на таких интерактивных порталах (amazone.com), IE9 там рулит, в отличие от IE8.

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

Вообще это было о том направлении развития современного мира, которое меня сильно огорчает. Потому что понятно, что в первую очередь все это используется в маркетологических целях. А во вторую — в области политтехнологиях. И если раньше от информации изолировали, то теперь идет наоборот большой поток рекламы и лапши на уши, так что к до ценной информации не дойти. Но все это, увы, объективная тенденция, проистекающая из нынешнего устройства мира.

Ричард Соули (OMG) CISQ: управление качеством ПО становится дешевле (4)

Может быть, я недооценил этот доклад. Потому что в целом Object Management Group вызывает у меня определенное уважение как организация, продвигающая и вырабатывающая технологии. А доклад был о выработке стандартов как средстве улучшения мира. И в некоторый момент я ушел искать, что еще есть.

Начал с многодневного пожара в Балтиморе в 1904, когда выяснилось, что пожарные рукава нестандартны, поэтому их не получалось соединить для длинной перекачки воды. И после этого в штатах задумались о стандартизации…

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

Мое отношение к стандартам не столь радужное. Со времени пожара в Балтиморе прошло очень много времени, а жизнь особо не изменилась. В новых областях каждый из лидирующих гигантов продвигает свои собственные решения, и стандартизации на уровне реальной совместимости — не возникает. Стандарты получаются некоторым компромиссом, фиксирующим допустимость нескольких вариантов. А еще — стандарты стали способом заставить потребителя обновить то, что ему реально менять не нужно. В основном тут речь идет о железе, когда новые стандарты разъемов или размеров требуют заменять вполне рабочие компоненты. Но в ПО это тоже есть, хотя тут недавно произошел практически уникальный кейс от MS — когда был выпущен пакет к офису 2003, позволяющий читать сделанное в офисе 2007.

Луис Олсина (Национальный Университет Ла Пампа) Оценка качества приложений Web X.0 (4)

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

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

Далее — заметки.

  • Введение — долгое. линия: 1.0 статика и динамика, 2.0 online interaction
  • mobile — personalise context due to restrict of device
  • 3.0 — semantic web…
  • 2.0: continious dev, no final reliase, social network — facebook
    • особенности — ориентация на контент, интерактивность
  • качество — модель, …
  • много стандартов
  • качество — сложное понятие. garvin в 87 define various view on quality
  • difference characteristic. differ between programmer and end-user quality
  • quality — relationship between attributes of entity/process and specific потребностей
  • simple ER-diagramm for store quality facts/measures.

Ликбез, лекция причем во многом — про стандарты.

Бьярн Страуструп (ATM) Введение в C++0x (7)

На докладе был аншлаг, живая легенда. Сам доклад — в хорошем академическом стиле, размерно и очень монотонно. Но при этом — уложился в регламент, и за это отдельный респект.

Ничего нового для меня не было, на ADD Елена Сагалаева примерно тоже рассказывала, только более живо. Авторской позиции, интересных подробностей или концепций — тоже не было. Жаль.

Далее — заметки.

  • Эмитология языков. Доменные начались с fortran и cobol, из них simula, вторая цепь — ассеблер, pcl, c. C плюс simula дали c++, а из него — java, C#, C++0x.
  • C with class — 80, C++ 84. Стандарт 1998.
  • Но! в выработке стандарта присутствовали основные игроки, а конечные пользователи — нет — это плохо
  • Цель:
    • c++ — для системного программирования и библиотек;
    • упростить обучение.
  • Стандарт — не научная фантастика, feature где-нибудь реализованы, в разных компиляторах
    • stability and compatibility правда полной не достигли — ключевые слова, типы. Но! выявляются компилятором, более-менее формально.
  • фичи — я не записывал, он о них подробно рассказывал
  • библиотеки — полезны, монгут вводить типы, а если в типах реализованы определенные методы, то их можно использовать в операторах, например, итератор для for или инициализатор из списка.
  • местами тронули семантику, передача/возврат больших объектов без копирования
  • безопасность — перечисления, частичная сборка мусора…
  • и так далее, многое — многопоточность, лямбды и т. п.

Концепция C++ сохраняется — build soft infrastructure sysytem programming.

Финальный стандарт будет в будущем году (через год), а компилятор, он думает, появится раньше.

Новые идеи на модельных задачах

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

Таланов и другие (Fujitsu) Автоматизация производства ПО при помощи Concept mining (8)

Полный список авторов и название: Максим Таланов, Андрей Крехов, Айдар Махмутов (Fujitsu Technology Solution) Автоматизация производства ПО при помощи Concept mining и использования вероятностных рассуждений поверх семантической базы знаний в области софтверной инженерии.

Ребята делают систему, которая позволит автоматически исполнять change request’ы заказчика, сформулированные на естественном английском языке, с аудитом аналитика, выдавая готовый код (sic!!). Пока у них демо на модельных примерах, в этом году запланирован выход в продакшн и они оценивают, что смогут до 25-60 % запросов на изменение своих приложений обрабатывать автоматически. Потому как тупые запросы. А сложные — да, к программистам, как сейчас.

Основные идеи таковы. Пока мы копаем код лопатой, а нужно — экскаватор. Пока не изобрели. Есть генераторы, но нельзя сделать merge, точечно вмешаться, достроить порождение по аналогии. Потому что приложения-генераторы — не понимают, что делают, там тупой формат кода. А хочется — интеллектуальной генерации по некоторому близкому к естественному описанию. Упоминались какие-то предшественники, но я не запомнил. Была простая система, прототип. Но желание довести до продакшн. Добавить самообучение по опыту. Питер Морг и Бертран Рассел. И это не ИИ, решаем только простые задачи.

Для обучения — память, знания а не данные RDB storage, лингвистика — stanford parser, понимательный компонент — самое сложное, пытается сопоставить предикаты с моделью. Генератор идей — самый проработанный, стохастический генератора и тренер — зубрежка. Если по аналогии нашли решение, ок, иначе — стохастическая генерация, вероятностная логика. Оценивает эксперт.

Описание предметной области у них опирается на структуру данных, при этом они формулируют ее не как текущее состояние, а в развитии — добавили таблицу, добавили атрибут, добавили экран на интерфейсе, добавили туда таблицу, добавили кнопки. Естественно, кроме добавления есть удаление и изменение. У них есть импортер для проектов в это представление (в докладе не было, я потом спрашивал). Идея в том, что и запросы на изменение — они примерно в таких требованиях формулируются. И выполнив один запрос ты имеешь фактически алгоритм для выполнения класса запросов «по аналогии», то есть с заменой каких-то переменных, например, имен таблиц и полей.

Сейчас блок с естественным языком еще не подключен, только эксперименты. И это — ближайшие планы, плюс импорт данных по существующим проектом, создание моделей. Если модель от импорта будет не качественной — не страшно, будет ошибаться, потом научится.

В текущем представлении, на котором отлаживаются — 3 тысячи концепций, как-то оно работает. Проект лежит на google source (вроде), после презентации можно было взять CD с демо. Я взял, но еще не смотрел.

Слушатели сходу восприняли это как идею полноценного ИИ либо как слишком формализованное описание. Хотя тут идея красивая и промежуточная — отсеять понимаемые запросы и их делать. И пошли вопросы на тему. как со сложными задачами (хотя они сразу сказали, что сложные программисту). И тезисы о том, что в таком минимальном объеме делать явно не стоит, а лучше бы было сделать совсем другое, например, доработать генерацию, или управлять приложением через метаданные. Авторы отвечали, что им нравится именно выбранный путь, другие они знают, но идти не хотят. В целом — имеют право — эти вопросы касаются только того, кто финансирует работы.

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

Богумила Хнатковска и Пётр Кубиц (ВУТ, ИИ) Трансформации логической модели данных (4)

Полное название доклада — Трансформации логической модели данных (LDM) на основе нефункциональных требований. Докладчики — из Wroclav Univercity of Technology. Доклад был посвящен различным формально выполняемым преобразованиям логической модели данных, в основном — касающихся денормализации, для обеспечения заданных требований по производительности. Основная идея состоит в том, что если для системы построить предполагаемую частотную модель запросов на чтение и изменение данных. то для заданной логической структуры можно оценить быстродействие. Ну дальше — варьируем структуру, оцениваем, выбираем лучшее. Оценку можно вести как расчетно, с применением некоторых весов, так и на некотором эталонном тесте. С моей точки зрения, идея чисто теоретическая, так как требует сильно большой проработки деталей на начальных фазах проекта и не реализуема в реальных условиях, особенно в итеративной разработке.

Для себя я отметил в докладе аббревиатуры PIM (phisical independent model) и PSM (phisical specific model) как синонимы логической и физической структуры данных.

Далее — заметки.

  • iso9126
    • внутренняя и внешняя модели качества
    • внутренние характеристики, их отражение на внешние.
    • производительность time behavior
  • pim2psm transformation — difficult
    • instead horisontal transformation
    • psm2code
  • refactor logical data model to solution of nonfunc req
    • nonfunc req -> effitienct (time behav) -> predict db productivity
    • automatic transformation?±
    • example table? column/ type
  • optimization:
    • number of joins
    • number of columns to be updated
    • number of indexes for querys and for update
  • extend metamodel — add operations, not only structure of data
  • algorithm step — add index, or add join tables
  • metric for optimisation — cost of operation, sum by all operations
    • optimisation decition
    • informal definition and than refactoring model…
    • test cases, measure — for each refactoring variant.
  • sample
    • storage information about student, cources, dept.
    • честно расписано… и преобразование структур посчитано — денормализация
    • на практике не использовалось, теория

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

Реальные проекты и практики без методологии

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

Дмитрий Овечкин (Grid Dynamics) Трехуровневое планирование, контроль и реагирование (5)

Полное название доклада — «Трехуровневое планирование в Agile, контроль и реагирование». Agile я опустил, потому что для докладчика смысл в этом слове — не RUP, по которому они вроде работали раньше. Хотя, есть у меня подозрение, что их практики раньше так же напоминали RUP, как нынешние — agile. Дело тут не столько в вольном понимании практик, это agile как раз поощряет, сколько в плохом владении теорией — автор знает ее сильно по-наслышке, и местами, излагая ее и соотнося с их практиками, говорит прямо противоположное тому, что в теории сказано.

Но если очистить доклад от теории, оставив практику, то получается относительно интересно, хотя лично для меня — достаточно очевидные вещи.

Итак, раньше докладчик работал на rup, а потом узнал про agile и начала интересоваться. Дальше был краткий экскурс в теорию agile, как он ее понимает, очевидное, а местами путанное. Про двухуровневое планирование в agile — продукт и спринт backlog. Про истинный agile и nokia test, при этом начала смешать scrum и agile (тест про scrum, а его не поймали).

Но очень быстро перешел от теории к практике у них. У них аутсорсинговая компания, несколько взаимосвязаных продуктов, по заказчикам, может быть это ветки одного продукта. но сильно отличающиеся. Backlog они создали, с кроссфункциональностью есть проблемы, с оценкой — тоже. Сделали спринты в рамках релизов на 2, потом 3 недели. Но вот с потенциально отгружаемым продуктом — сложности из-за тестирования вручную, сейчас вложились в автотесты.

И главная тема доклада — планирование. Оно у них трехуровневое.

  1. Квартал. Это условия заказчика. И оплата по кварталам. На квартальном плане сшивают загрузку по разным проектам, балансируют.
  2. Спланировали квартал — переходят к планированию релизов, с учетом квартальных планов. Только для этого надо оценить backlog релиза.
  3. backlog спринта — кроспродуктовый, потому что команды — универсальные! с соблюдением процентов квартального планирования. Продукты — связанные.

Тут интересный вопрос, кто планирует и оценивает, об этом был вопрос. Реально планируют квартал менеджеры, релизы — по обстоятельствам, спринт — команда, согласование — творчески, но детали не осветил. Product owner у них общий на все продукты. Задачи в backlog — 8-13 человеко-дней!

Еще вопрос с изменениями. Если идут изменения, то равноценный обмен. И спринты и релизы и кварталы, если не просто перестановки. Потому что не резиновые.

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

Такая вот практика.

Евгений Зуев (Интерстрон) Семантические интерфейсы языков программирования (4)

В целом интересно и живо, и архитектура быть может интересная. Только докладчик ушел в свой проект — компиляторы С++ — много лет назад, и так в нем и живет. А мир — стремительно идет вперед и обогащается новыми идеями. По моим оценкам, это — уровень 2003 года, а то и раньше — потому что какие-то идеи этих времен были вообще в далеком прошлом развития Unix, Lex, Yacc. А сейчас — время конструкции .Net с компиляторным многообразием, инвариантным представлением, метаданными, посткомпиляторами, языковыми плагинами и тому подобным. Над всем этим работают мощные фирмы, и здесь малая фирма, стремящаяся обиходить большую нишу — заведомо проиграет, потому что в большой нише идей недостаточно, надо по площади работать. А у них, при всех идеях — все в разработке, бета-тестирвоание не начато. Так что впечатление было двойственное — с одной стороны, я вспоминал и опознавал конструкции, проблемы, идеи и подходы к решениям, известные в молодости. а с другой — четко осознавал насколько это отстало и чем заменилось в современном мире. И оценка, равно как и классификация — она как раз за вчерашний день в предмете доклада.

Дальше — заметки.

  • Semantic С++ инфраструктура построения компиляторов и построения кода
  • Расширяемая, средства семантического поиска, парсинг собственный (считает, что использовать уже написанный — хуже, чем писать свой, потому что встраивать дорого).
  • Аналоги: asis, sage rose pivot cci
  • Эволюция архитектуры компиляторов
    • Традиционно — внутри компилятора черный ящик, снаружи не видно
    • Таблицы выносят промежуточное представление с которым дальше работают разные части — генератор кода.
    • Визуализатор, статический анализатор и так далее. gnu-коллекция компиляторов
  • Идея — семантическое представление становится первичным. Получение — дело техники. Из разных источников — текст, диаграммы… компилятор спрятал внутрь, вместо начальной конструкции, когда компилятор снаружи. Я: халява это, реально на схеме просто альтернативные способы получения.
  • Семантическое представление — на объектно-ориентированных принципах, структура программы. В принципе, понятно.
    • Но представление сложное: многозначность, класс — тип, структура, область действия и что-то еще. поэтому модель строят…
    • Очень хочет соответствие с языком. Я: а как же VS.Net, где множественность языков и инвариантное представление?
    • Вербализация скрытой семантики, например, вызов деструкторов…
  • Пример классов … там в числе прочего — поиск по шаблону или как-то еще. Функции check и validate — проверки компонентов на месте, семантики правильности.

Я: Не очень понятно/совсем не понятно — в чем ценность и место. В принципе это все ваяли 100 лет назад. Ну и показал структуры данных. И что?

  • семантическое представление — древовидное и xml, полное равноправие. Я: тоже очевидная и давно реализованная идея — описать c++ через xsd
  • все в разработке бета-тестирование не начато

Вячеслав Нестеров (EMC) Круглый стол по аутсорсингу в России (3)

Полное название — Круглый стол: Центры по разработке ПО международных компаний в России. Достижения и проблемы.

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

Я был в самом начале. Услышал много жалоб менеджеров на трудность бизнеса.

  • Правительство не решает проблемы. Конечно, местами заботится и не оставляет вниманием, но проблем много. Что заботится — льготы дает, ЕСН вроде будет 14 % вместо 34 % Я: зачем там льготы — непонятно совершенно и нечестно по отношению к остальным. Хотя причины — понятны — лобби, это организованная сила и можно протащить как инновационную деятельность. А про проблемы — например, таможня. Чтобы ввести новый девайс, особенно если в нем шифрование (а сейчас все такие) — два месяца разтаможки и это — проигрыш по срокам перед другими аутсорсерами в странах без таких проблем. Но с этим они работают и надеятся на позитив.
  • Кадров нет. Рынок в кризис чуть ужался, но этим летам вышел на докризисный уровень, и программисты хотят обалденных денег. Я: естественно, аппетиты программистов будут расти — хотят они в нашей стране жить не хуже, чем в Европе и не видят причин — почему должно быть не так. А стоимость этого — дорожает вместе со всем остальным.
  • А еще квалификация после вуза у сотрудников — вовсе не та, что нужно. Плохая гибкость образовательной системы. Я: в общем, системная и понятная проблема. Но если фирма крупная — учите своих, как яндекс. Или с ВУЗами кооперируйтесь, но деньги платите. А они — на халяву хотят.
  • А еще — приходится конкурировать за программистов с inhouse разработкой
  • Индустрия подвижная, программисты молодые и падкие на новые технологии :)

В общем, тут я понял, что слушать поток жалоб от менеджеров аутсорсиноговых компаний на сложность их работы — я не готов, и ушел.

Презентации современных инструментов

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

Олег Пустошило (Системные технологии) Система электронного документооборота в коммерческом банке (4)

В докладе речь шла о продукте на основе Lotus Notes, обеспечивающий документооборот, связанный, преимущественно, с кадрами. По сути это набор определенных настроек. Обеспечивается система фактического организационного учета сотрудников, которая часто отличается от бухгалтерского, интеграция с кадровой системой при ее наличии и опрокидывание организационных ролей в систему прав в различных информационных системах. И почтовые уведопмления по необходимости.

Традиционный путь докладчик представлял как 1C + кадровая система с переходом на Lotus или SharePoint при увеличении организации с заменой ими кадровой системы, а свой путь презентовал как возможность развития с сохранением действующей системы и интеграции с ней. Это несколько непонятно, особенно для банков, где важное место занимает операционная система (АБС).

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

Антон Игнатов (IBM) Решения IBM для финансового сектора (3)

Полное название: «Решения IBM для финансового сектора — реальные активы для разработчиков. Обзор инструментальных средств в рамках IBM Banking Framework». Скучный рекламный доклад от вендора по всей широкой линейки продуктов IBM от хранилищ данных до инструментов разработки и управления Rational. По общедоступным материалам, без каких-либо изюминок, с рефреном о превосходстве IBM по определению, хотя славная история, естественно, не гарантирует превосходство в конкретном сегменте.

Вадим Ипатов (ИнтерТраст) Некоторые проблемы систем электронного документооборота и пути их преодоления (4)

В целом доклад был про создание распределенной системы документооборота на основе Lotus Domino. У них есть некоторый подход для этого, плюс базовая реализация, которую можно развертывать на конкретном предприятии. В принципе, ничего нового или интересного в подходах — не было.

Начался доклад с некоторого ликбеза, плюс рассказа про централизацию/децентрализацию. И далее был сформулирован «новый» федеративный подход, который заключается в том, что у каждого документа есть узел-владелец, по которому определяется, откуда идут реплики. Выстраивают топологию по оргструктуре. На вопрос про общий контент — ответ, что проблема не решена.

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

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

Андрей Уразов (Parasoft) Банковское ПО без ошибок и уязвимостей безопасности (3)

Доклад на банковском дне, в основной программе у него же доклад «Программирование, ориентированное на качество», и я подозреваю — с тем же контентом. Потому что банковской специфики в докладе не было.

Докладчик немного рассказал про средства автоматического анализа кода, после чего перешел к рекламе средства от Parasoft. Отчасти аналогичный по позиции доклад был на ADD-2010 (Андрей Карпов. Устаревание стандартов кодирования и статический анализ кода), но там докладчик был в контексте существующих систем, дал хороший сравнительный анализ в котором их система была одна из многих. И саму задачу раскрывал достаточно широко, указывая конкретные современные применения, например, при переходе на 64-битную архитектуру. А здесь — из существующих систем докладчик называл lint :(. А саму систему — как автопроверки при commit в cvs по ночам. В целом — докладчик вне контекста современных технологий.

Андрей Совцов (Embarcadero) Пути повышения качества баз данных (7)

Это был весьма качественный вендорский доклад, был на банковском и основном дне, потому что компания — спонсор. Компанию я не знал, а она оказалась вполне почтенной, как я посмотрел в wiki, основана в 1993 году, занимается инструментами для баз данных, а в 2008 совершила рывок и купила CodeGear вместе с Delphi. Но доклад был не о Delphi, а об основной специализации. У компании есть миссия и это мне понравилось, хотя точную формулировку я не запомнил. Смысл в том, что она дает широкую линейку инструментов, одинаково работающих со всеми базами данных, и, образом, позволяет однородно администрировать и разрабатывать в неоднородной по платформам среде.

Основные компоненты линейки:

  • ER/studio — аналог Erwin
  • DB Aristan — средство DBA, подержка рутины
  • Performing center — мониторинг текущий
  • DB optimizer — оптимизация конфигурации БД и запросов
  • Change manager — накат изменений на БД, включая некоторый анализ скриптов от сторонних производителей, когда тебе прислали «новую версию системы».

Фишка в том, что все БД интерфейсно и понятийно представлены одинаково. На уровне ER-диаграмм оно понятно, а вот на уровне администрирования и оптимизации — достаточно впечатляет.

Александр Орлик (Craftware Ltda) Реализация захватом с помощью UML (4)

Фактически, доклад презентовал тулу на http://enterpriseanalyst.net, которая умеет сопоставлять UML-модель с ее реализацией. В том числе, если реализация несколько отличается от описанной модели, например, атрибут представлен методом. Вроде как возможны преобразования в обе стороны, а саму тулу — можно скачать. У меня особого интереса не возникло, набор преобразований и идееи — не заиграли. Хотя, может, для тех, кто реально моделирует приложения на UML будет интересно.

Надувание научных щек над практикой

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

Григорий Гусев (Люксофт) Практическое рецензирование требований к программным (3)

Реально доклад был о том, как они нагнули заказчиков, снизив им уровень сервиса под видом борьбы за качество и эффективность разработки, но не обеспечили ни того ни другого. Вернее, они смогли констатировать, что стоимость разработки не возросла. Что касается качества, то оно увеличилось внутри — они стали меньше переделывать собственный код. Правда, без переделок разработка не стала менее трудоемкой :)

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

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

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

С их точки зрения, получилась итеративная разработка вместо последовательной, псевдоитерации в рамках водопада. Ну и количество изменения требований уменьшилось, что не удивительно при столь тщательной проработке.

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

В вопросах интересовались, почему же столь замечательных практик нет в стандарте процесса, cmmi. Докладчик сказал, что в принципе нечто есть, отослал к technical solution.

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

Кстати, Гера в свое время, обосновывая практику работы СМ с нами соглашался оплачивать почасовку именно для того, чтобы обеспечить скорость реакции на требования, без детальной оценки. А еще — чтобы мы не закладывали свои риски. Их клиенты нагнули на fixprice и получили такую фигню…

Сергей Зыков (ВШЭ) Методология шаблонно-ориентированной разработки приложений (3)

Полное название доклада — Интегрированная методология шаблонно-ориентированной разработки и сопровождения корпоративных приложений. И эта заявленная глобальная тема в реальности обернулась весьма скромной системой метаданных, с помощью которых устанавливается соответствие между типами объектов в разных системах. При этом соответствие между экземплярами выстраивается алгоритмически, таблиц соответствия ключей не ведется. На этой базе была выстроено соответствие в данных по сотрудникам между тремя системами — видеоархивом, системой учета персонала и oracle applications управления финансами. Те, кто реально занимается интеграцией, представляют скромный объем задачи, тем более, что выстраивать систему опознания экземпляров не потребовалось. При этом, однако, в докладе развернута большая методологическая платформа вокруг всего этого — начиная от петабайт объемов данных в современных корпоративных системах, через математическую модель предметной области и модель жизненного цикла, диаграммы, доменную модель, описание трансформации данных на языке «близком к естественному», который потом трансформируется в uml-модель и прочими наворотами. И — да, есть сложности с персоналом сопровождения — ему приходится всем этим овладевать, но в большой гетерогенной среде это оправдано. В целом — это типично научный, оторванный от реальности подход когда для небольшой задачи строится большая и сложная система, а потом это дело не взлетает — именно из-за неадекватной сложности, и — не взлетит. Зато — это научная работа… Говорят, автор не первый год выступает на эту тему с одним примером. Да, я не хочу сказать, что вся наука такова, но такой — много, и здесь — ее пример.

Из мелочей — народ, услышав про видеоархив, тут же заинтересовался — а как индексация идет, работают ли какие-то системы распознавания и получил ожидаемый ответ — описания вводят вручную. А еще они, естественно посчитали для своей системы интеграции возврат на инвестиции — по сравнению с ручным вводом.

Далее — заметки.

  • Корпоративные системы. Шаблоны, гетерогенная интеграция, большие объемы данных… говорит — петабайт (intel 2005 3.2)

После перерыва…

  • Перейти-таки к традиционно кейс-средствам генерации. но сначала — строить математическую модель. Визуальный язык и кейс-подобное средство проектирование, выстраивать в репозитории данные…
  • Правда практически они проектированием по шаблонам не занимались
  • Новая модель жизненного цикла, обогащенная всякими кейс-средствами.
  • Найти шаблоны, образцы подсистем… problem domain modeling…
  • Отнесение объекта к классу — прерогатива системного аналитика… много формул…
  • Из доменного подхода строят математическую модель…
  • Трансформация описаний на языке, «близком к естественному» в uml-диаграммы и далее в код. Но автомат — от формального описания

Интеграция — видеоархив, учет персонала, oracle applications управления финансами.

  • Система управления контентом — модуль с метаданными и администрированием
  • Есть сложности — обучение, овладение кейс-средствами. Но оправдано при существенной гетерогенности
  • Сделали для большой нефтегазовой международной компании и вполне достойно (вроде?)
  • Оценили совокупную стоимость и возврат на инвестиции… ха-ха!
  • Есть ряд внедрений элементов методологии, помимо упомянутой (включая ИПУ)
  • Видео индексировали вручную. если описаны варианты — удобно искать.
  • Тысячи классов! в модели.
  • Окошки заполняют… как с экземплярами — непонятно
  • Конфликты — предметный эксперт, приоритетные сущности.
  • По сути первичка — в управлении кадрами. И все связано какими-то автоматами, сопоставления ключей нет
Источник — «https://mtsepkov.org/index.php?title=SECR-2010&oldid=7331»