CustisWiki - Новые страницы [ru]

Автоматизация банковской отчетности: каждому свое приложение

2011-08-17T10:38:03Z

Пресс-служба: Новая страница: «;Елена Старынина: руководитель проектов, аналитик на...»

Елена Старынина: руководитель проектов, аналитик направления «Финансовые институты» CUSTIS

Национальный банковский журнал, № 8, август 2011. http://www.nbj.ru/publs/upgrade-modernizatsija-i-razvitie/2011/08/09/avtomatizatsija-bankovskoi-otchetnosti-kazhdomu-svoe-prilozhenie/index.html

Можно ждать или не ждать изменений, но они все равно произойдут. Изменения в бизнесе и отчетности банков динамичны и происходят с некоторой периодичностью. Каждый специалист по отчетности знает, что изменение требований к формированию отчетов неизбежно, ведь меняются и условия бизнеса, и правила, устанавливаемые ЦБ РФ.

Использование сертификатов для web-приложений (Максим Высоких на ADD-2010)

2011-08-09T17:52:30Z

StasFomin:

Интервью с Еленой Ивановой (для SQADays, 2011-07-20)

2011-08-09T14:34:14Z

StasFomin:

Интервью с Еленой Ивановой провела Маргарита Сафарова.

Краткое содержание в картинках:

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Интервью с Еленой Ивановой (для SQADays, 2011-07-20)»

Интервью с Дмитрием Ручко (для SQADays, 2011-07-27)

2011-08-09T14:32:24Z

StasFomin:

Интервью с Дмитрием Ручко провела Маргарита Сафарова.

Краткое содержание в картинках:

Репликация: База Знаний «Заказных Информ Систем» → «Интервью с Дмитрием Ручко (для SQADays, 2011-07-27)»

Ахиллес и черепаха. Разумный подход к работе над крупными клиентскими проектами (Юрий Гугнин, AgileDays-2011)/Заметки Стаса Фомина

2011-08-05T16:44:02Z

StasFomin: Новая страница: «Сразу видно менеджера из творческого мира. И заказные проекты у них называются «клиентски...»

Сразу видно менеджера из творческого мира. И заказные проекты у них называются «клиентские», и апория Зенона, вынесенная в заглавие понимается^[1] как смешная байка, прозвучавшая в начале фильма Такеши Китано про тяжелую жизнь художников, и еще смешнее эта апория была понята:

Вам неправильно кажется, что «Ахилес — круто, а черепашки — ~~наруто~~некруто». На самом деле черепашки рулят.

И смысл выступления в том, что автор страдает от гигантомании крупных заказчиков (перечисленных с плохо скрываемых хвастовством), приводящих к

огромным ТЗ («ТЗ 300 страниц по сайту, мы сами не можем его прочитать»)
здоровым группам согласования
ну и в целом, попытка сделать все разом, «в едином корпоративном стиле», приводит к появлению очередного УГ.

Как дизайнер, разумеется «аппелировал к Applу», который для каждого продукта делал отдельные сайты с самостоятельным дизайном, да и с точки зрения здравого смысла, глупо делать один и тот же дизайн для разных банковских продуктов, с разной аудиторией и жизненным циклом («Я не знаю того, кто берет ипотеку два раза в жизни. Разве что кто-то живет 150 лет»©).

И конечно, автор призывал «есть слона по частям» («Ни под каким предлогом на водопад не соглашайтесь» ©), чтобы и группы согласования были маленькие, и успехи, и у исполнителя и у представителя заказчика, были хоть небольшие, но почаще, что лучше одного глобального epic failа.

Да, уровень клиентоориентированности высок: «Помогайте менеджерам со стороны клиента продвигаться по карьерной лестнице» (кстати, мы уже два года как клиент ADV, и это многое мне объясняет).

↑ Похоже автор действительно не в курсе…

Типы личности и их проявление в жизни и работе (семинар 2008-02-12)

2011-08-05T15:30:23Z

StasFomin:

Семинар «Типы личности и их проявление в жизни и работе» — по типологии Майерс-Бриггс. По книгам Отто Крегера «16 типов личности…» и сопутствующим материалам из инета.

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

Everyone likes change, but nobody likes to be changed (Henrik Kniberg, AgileDays-2011)/Заметки Стаса Фомина

2011-07-30T18:55:02Z

StasFomin:

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

Ларчик открывался просто. Отсутствие реального опыта. У Хенрика есть ребенок, но ему только пара лет (2008 года выпуска) — мотивировать на уборку еще рано.

Впрочем, самый главный вопрос — а нужно ли это (ребенок, убирающий игрушки перед сном)? Хотите, чтобы у вас было так?

► Хотите узнать, почему вы это не хотите?

Потому, что это аутизм.

Веб-разработка на GWT и mvp4g (Антон Котенко, ADD-2011)

2011-07-27T10:18:57Z

StasFomin:

VirtualDub

2011-07-26T19:14:25Z

StasFomin:

Универсальный швейцарский нож видеомонтажа.

SASL, SVN, Mercurial и Bazaar

2011-07-20T10:26:02Z

VitaliyFilippov:

Те, кто предпочитают использовать SVN через встроенный легковесный сервер Svnserve (вместо Apache и mod_dav_svn), вместе с интегрированной Windows-доменной авторизацией через SASL, могут столкнуться со странной ошибкой:

В command-line клиенте SVN из дистрибутива от CollabNet (с дистрибутивом SlikSVN все ОК):

svn: Cannot negotiate authentication mechanism

или что-то типа

subvertpy.SubversionException: ('Cannot negotiate authentication mechanism', 210007)

в Bazaar, который умеет работать с SVN-репозитариями, используя subvertpy.
в Mercurial, который может работать с SVN, используя дополнение hgsubversion, которое, в свою очередь, использует SWIG-биндинги WinSVN или тот же subvertpy.
вероятно, аналогично и в Git — там для работы с SVN используется Perl-модуль, основанный на тех же SWIG-биндингах.

Причина — неполный набор DLL’ек библиотеки SASL-аутентификации в сборках от CollabNet. Конкретно, обычно не хватает saslLOGIN.dll и saslPLAIN.dll, которые как раз нужны в нашей офисной конфигурации.

Итак, чтобы «починить» CollabNet-oвский клиент, нужно залить в него все SASL-DLLи (разумеется, соответствующей «битности»), полный набор которых, кстати, есть в дистрибутиве TortoiseSVN (от того же CollabNet):

saslANONYMOUS.dll
saslCRAMMD5.dll
saslDIGESTMD5.dll
saslNTLM.dll
saslLOGIN.dll
saslPLAIN.dll

И затем убедиться, что в реестре следующим образом прописаны пути к этим библиотекам (первый путь ищется под 32 битами, второй — под 64):

Windows Registry Editor Version 5.00 
[HKEY_LOCAL_MACHINE\SOFTWARE\Carnegie Mellon\Project Cyrus\SASL Library]
"SearchPath"="C:\\Program Files\\TortoiseSVN\\bin"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Carnegie Mellon\Project Cyrus\SASL Library]
"SearchPath"="C:\\Program Files\\TortoiseSVN\\bin"

Важный момент — пути прописывать без завершающего слеша! Библиотеке конечно позор — и за это, и за использование реестра (никаких portable-сборок), и за «Carnegie Mellon».

В случае с Bazaar — залить все эти библиотеки в папку lib дистрибутива, и то же самое с реестром.

Mercurial у меня питоновский, по крайней мере расширение hgsubversion все равно требует Python с установленными SVN-биндингами, так что там проще поставить subvertpy (хоть easy_install-ом), а потом перегрузить в папку с subvertpy все DLLи из «полного» CollabNet-дистрибутива (то есть дополненного тортилловыми SASL-библиотеками), и опять-таки вправить мозги реестру.

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

Если кто-то готов посоветовать лучшее решение (можно ли пересадить в Python 2.7 SVN библиотеки от SlikSVN, в общем, чтобы не было завязок на реестр) — [mailto: stas-fomin@yandex.ru посоветуйте].

MediaWiki — серебряная пуля или швейцарский нож? (SEF-2009)

2011-07-15T18:01:43Z

StasFomin:

Докладчик: Стас Фомин

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

Да, с этим докладом уже было выступление на SECR-2009, но для SEF-2009 была подготовлена специальная, экстремальная версия. Если SECR-овский доклад состоял из 112 слайдов на 40 минут, то для SEF-2009 в те же самые 40 минут пришлось уложить 100 слайдов и еще 15 минут скринкастов.

Как это возможно? Оказалось возможно. Был опробован принципиально новый вид презентации — презентация под заранее записанное видео.

Такой тип выступления весьма нетривиален для докладчика, однако удалось держать внимание зала от и до.

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

Сразу после доклада мы раздали полсотни флешек с «нашей инсталляцией» MediaWiki, устанавливающейся простым копированием под Windows, с рядом наших уникальных доработок и расширений. В общем, так, чтобы можно было бы моментально начать использовать MediaWiki персонально, или для небольшой (до 100 чел.) рабочей группы с рядом наших уникальных доработок и расширений.

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

Репликация: База Знаний «Заказных Информ Систем» → «MediaWiki — серебряная пуля или швейцарский нож? (SEF-2009)»

Domain Specific Languages, теория и практика (семинар 2011-06-23, для студентов)

2011-07-15T17:26:07Z

StasFomin:

Недостающая часть Scrum — как стать успешным инженером в Agile? (Антон Кекс, AgileDays-2011)

2011-07-12T20:03:30Z

StasFomin:

Швейцарский нож аналитика - визуализируем логи одной строкой! (Евгений Кирпичёв, ADD-2011)

2011-07-07T08:40:16Z

StasFomin:

Agile in Investment Banking (Сергей Евтушенко, AgileDays-2011)/Заметки Стаса Фомина

2011-07-06T16:39:31Z

StasFomin:

Название надо немного уточнить — конечно, речь не идет о том, чтобы гонять на скрам-митинги самих банкиров, речь идет о разработке систем для инвестиционного банкинга, это корпоративная разработка характеризуемая:

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

В этой области работает широко известный в узких кругах Умпутуном, и работал печально известный Сергей Алейников, который променял ежегодние $400×10³ на 8 лет тюрьмы.

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

Так вот, там не работает стандартный Agile-Парето-подход, когда идет размен scope на сроки — тут требуется все и сразу (full scope/fixed deadline). Плюс заказчики далеко за океаном (аутсорсинг на Украину), большие лаги в коммуникации. Не самая хорошая позиция для игры в аджайл.

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

Распределенные совещения удалось улучшить с помощью софта:

дейлискрамы шли с расшаренными экранами
оценка задач шла через http://planningpoker.com

В общем — резюме, не пытайтесь применять все SCRUM-практики, если вы попали в такую плохую ситуацию.

Темпл Грандин (рецензия Стаса Фомина)

2011-07-05T11:32:55Z

VitalyKozlovtsev:

Метафора «программисты=психи, пользователи=нормальные → психов нельзя допускать», продвигаемая в Психбольница в руках пациентов , имхо, неверная в корне.

Программисты и юзеры (включая «бизнес-пользователей»^[1]), это скорее два разных вида, разные миры. И если нужно сделать новый гениальный интерфейс, реальный прорыв (который потом вполне смогут копировать добротные ремесленники), то тут нужен именно посредник между мирами, некий Вий, по крайней мере сумашедший.

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

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

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

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

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

Кстати, можно посмотреть ее короткое выступление на TED

http://www.ted.com/talks/temple_grandin_the_world_needs_all_kinds_of_minds.html

где говорится именно о свойствах альтернативного мышления. Заодно будет интересно потом смотреть художественный фильм (там подобрали очень похожую актрису). …

↑ Громкое название, но под этим имеются в виду обычные клерки и кассиры, и т.п.

IT people — правила игры на рынке труда (круглый стол, ADD-2011)

2011-06-29T22:41:20Z

StasFomin:

AgileDays-2011: Отчет Беспальчука И.А.

2011-06-25T15:38:29Z

StasFomin:

AgileDays-2011: отзывы в интернете

2011-06-24T18:08:48Z

StasFomin:

Фото

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2011: отзывы в интернете»

Agile и жизнь (Александр Калугин, AgileDays-2011)

2011-06-24T16:09:50Z

StasFomin:

Agile — вид из окна тренажёрного зала (Алексей Солнцев, AgileDays-2011)

2011-06-24T16:07:40Z

StasFomin: /* Аннотация */

Ахиллес и черепаха. Разумный подход к работе над крупными клиентскими проектами (Юрий Гугнин, AgileDays-2011)

2011-06-24T16:05:48Z

StasFomin:

Agile. Путь от хаоса к потоку (Николай Алименков, AgileDays-2011)

2011-06-24T16:04:52Z

StasFomin:

Зачем нам это надо? или Как продать Agile команде! (Михаил Карпов, AgileDays-2011)

2011-06-24T16:03:38Z

StasFomin:

Пуассоновое горение сроков (Андрей Бибичев, AgileDays-2011)

2011-06-24T12:55:33Z

StasFomin: /* Аннотация */

AgileDays-2011:Отчет Цыганкова Д.А./Пуассоновое горение сроков

2011-06-24T12:52:52Z

StasFomin: Новая страница: «У Андрея Бибичева был [[Пуассоновое горение сроков (Андрей Бибичев, AgileDays-2011)|самый удачный ...»

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

AgileDays-2011: Отчет Гребнева Н.Ю./Бибичев про сроки

2011-06-24T12:36:10Z

StasFomin:

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

Команды по Белбину (семинар 2010-01-19)

2011-06-23T19:11:05Z

MaksTsepkov:

Ведущие: Максим Цепков, Анна Сергеева
Дата: 19 января 2010

Типы личности (семинар 2008-02-12)

2011-06-23T19:07:38Z

MaksTsepkov:

Ведущий: Цепков Максим
Дата: 12.02.2008

Промышленное качество заказной разработки

2011-06-23T15:31:38Z

Пресс-служба:

Беспальчук Игорь: руководитель отдела технологического развития CUSTIS

Интервью опубликовано в газете PC Week Review: Автоматизация торговли, 7 июня 2011

Известно немало примеров, когда даже в таких массовых отраслях, как розничная торговля, компании предпочитают заказную разработку тиражному программному продукту. Об этом свидетельствует, в частности, опыт российской компании CUSTIS, которая на протяжении многих лет решает задачи автоматизации для группы компаний «Спортмастер». Научный редактор PC Week/RE Сергей Свинарев беседует с руководителем отдела технологического развития компании CUSTIS Игорем Беспальчуком.

PC Week: Какова сегодня ситуация на российском рынке приложений для розничной торговли?

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

PC Week: Что мешает заказчику выбрать продукт, уже представленный на рынке?

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

PC Week: Допустим, в организации уже используется ПО собственной разработки, которое устарело технологически, но содержательно всех вполне устраивает. Вы беретесь воссоздать такое приложение на более современной платформе?

И. Б.: Главная проблема здесь заключается в том, что предприятию, выросшему до определенного размера, становится крайне тяжело развивать такую «самописную» систему, поскольку при ее создании о вопросах последующего сопровождения и развития никто особо не задумывался. Иными словами, предприятие нуждается в более зрелом процессе разработки. Построение такого процесса требует особой экспертизы и высоких трудозатрат, но они впоследствии окупаются за счет способности системы к развитию, ее лучшей сопровождаемости, а также предсказуемости результатов и сроков разработки . Чаще всего мы не берем на себя сопровождение или развитие кода приложения, созданного на предприятии собственными силами, поскольку к этому моменту, как правило, уже сама собой назревает необходимость полной переработки информационной системы. Такая разработка, но уже базирующаяся на промышленных стандартах, и ведется нашими специалистами. Предварительно мы обследуем существующую систему и фиксируем все бизнес-процессы, которые она поддерживает, в том числе сложившиеся спонтанно и никем не документированные. Такой подход позволяет заказчику сохранить инвестиции, сделанные им ранее в бизнес-практики и системную архитектуру.

PC Week: А как при таком подходе происходит замена старого приложения на новое?

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

PC Week: Как в результате заказной разработки обеспечить промышленное качество программного продукта?

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

PC Week: Спасибо за беседу.

Репликация: База Знаний «Заказных Информ Систем» → «Промышленное качество заказной разработки»

Stratoplan World 2011-06-17

2011-06-21T17:35:19Z

StasFomin:

Динамичная миниконференция сообщества Stratoplan.ru из шести докладов.

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

Как внедрить ALM систему управления командами по разработке ПО и остаться довольным.(Заходяйченко Андрей, AgileDays-2011)

2011-06-20T18:44:04Z

StasFomin:

Первое приложение для IPhone (семинар 2011-06-09, для студентов)

2011-06-17T17:08:37Z

StasFomin:

Работа по принципу Lean в рамках всей компании. Опыт компании ESAB (встреча AgileRussia.ru 2011-04-14)

2011-06-14T18:01:34Z

StasFomin:

Nemerle Deep Dive (Владислав Чистяков, ADD-2011)

2011-06-14T17:40:10Z

StasFomin:

Генерация перестановок

2011-06-13T16:56:56Z

StasFomin:

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

Во-первых, заметим, что перестановки называются "Permutations". И можно многое найти по поисковым запросам http://www.google.ru/search?hl=ru&q=Permutations

очень хорошее описание алгоритма :

http://rain.ifmo.ru/~mikhalev/samples/disarray/disarray.html

При написании программ на C++, разумно использовать STL:

http://www.devx.com/tips/Tip/20816

Описание алгоритма и реализация на Pascal

На PL/SQL это выглядит примерно так (также долно работать, для перестановок с повторениями):

    _public_procedure({get_next_permutation},{
        _param({a_permutation}, {IN OUT NOCOPY pk_cmn.TStringArray},{},{Перестановка - массив 
                                                                        строк индексируемый с 1
                                                                        без пропусков})
        },{Получить следующую перестановку в лексикографическом порядке. 
           Если перестановка на входе последняя - то возвращается пустой массив
          (a_permutation.first IS NULL)  },
      {
      AS
        l_i PLS_INTEGER;
        l_j PLS_INTEGER;
        PROCEDURE swap(l_i PLS_INTEGER, l_j PLS_INTEGER) AS
        l_val VARCHAR2(4000);
        BEGIN
          l_val:=a_permutation(l_i);
          a_permutation(l_i):=a_permutation(l_j);
          a_permutation(l_j):=l_val;  
        END;
      BEGIN
        l_i:=a_permutation.count-1;
        -- поиск l_i
        WHILE (l_i>0)AND(a_permutation(l_i)>=a_permutation(l_i+1)) LOOP l_i:=l_i-1; END LOOP;
        IF l_i>0 THEN
            l_j:=l_i+1;
            --поиск l_j
            WHILE (l_j<a_permutation.COUNT)AND(a_permutation(l_j+1)>a_permutation(l_i)) LOOP            
                 l_j:=l_j+1; 
            END LOOP;
            -- меняем l_i и l_j
            swap(l_i,l_j);
            ---  переставляем  в обратном порядке от l_i до конца
            FOR l_j IN l_i+1 .. TRUNC((a_permutation.COUNT+l_i)/2) LOOP 
              Swap(l_j,a_permutation.count-l_j+l_i+1);
            END LOOP;
        ELSE 
            a_permutation.DELETE;
        END IF;
      END;
      },{})

Репликация: База Знаний «Заказных Информ Систем» → «Генерация перестановок»

Управление качеством ПО в Agile

2011-06-10T14:59:22Z

StasFomin:

Всеволод Коньков: ведущий разработчик компании CUSTIS, сертифицированный Scrum-мастер

Статья опубликована в журнале Intelligent Enterprise, № 5 (май) 2011, стр 42-45 ^[1]

Управление качеством продукции и услуг — одна из важнейших составляющих любого бизнеса, в том числе и информационных технологий, где вопрос качества стоит особенно остро. С чем это связано?
Дело в том, что порог входа на рынок разработки ПО относительно низок. Иными словами, чтобы стать поставщиком ИТ-решений, не нужны огромные инвестиции. По этой причине на рынке нет недостатка в предложениях по разработке ИТ‑систем для бизнеса. Однако часто предлагаемое ПО имеет неприемлемое качество, и это заставляет заказчиков очень внимательно подходить к выбору исполнителя.
В данной статье рассматривается достижение высокого качества ПО с помощью гибких, или Agile-методологий, которые в последнее десятилетие становятся все более популярными и среди небольших производителей, и у крупных вендоров (таких как Nokia и Microsoft). Agile позволяет добиться высокого качества ПО при относительно низких затратах, так как в гибких методологиях используются те же практики, что и в бережливом производстве (lean production).

↑ «Intelligent Enterprise» , № 5 (май) 2011, стр.42-45. http://www.iemag.ru/master-class/detail.php?ID=23232

CUSTIS запускает проект для Газпромбанка

2011-06-10T11:26:47Z

Галина Цатурян: Новая страница: «'''Пресс-релиз, 6 июня 2011, Москва''' '''Компания CUSTIS разработала Автоматизированную систему «...»

Пресс-релиз, 6 июня 2011, Москва

Компания CUSTIS разработала Автоматизированную систему «Главная бухгалтерская книга банка» (Главная книга) для ГПБ (ОАО). Система создана для поддержки централизованного учета в многофилиальном банке.

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

«Главная книга» представляет собой узел, в котором сходится информация из автоматизированных систем обособленных подразделений, и выполняет следующие функции:

Обеспечивает автоматизированное централизованное исполнение учетной политики в рамках многофилиального банка. Ведение в «Главной книге» таких объектов, как рабочие планы счетов, справочники контировок, справочники с правилами нумерации и именования лицевых счетов, позволяют, в сочетании с развитыми механизмами контроля, следить за соблюдением правил и ограничений, накладываемых учетной политикой банка.

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

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

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

Репликация: База Знаний «Заказных Информ Систем» → «CUSTIS запускает проект для Газпромбанка»

Системная архитектура

2011-06-10T10:30:37Z

Галина Цатурян:

Михаил Заборов: Руководитель направления «Торговые сети» CUSTIS

Финансовая газета — региональный выпуск (Москва), № 23 (июнь) 2011, стр.15.

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

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

Есть и другие сложности. Заказчик нередко плохо понимает, что ему нужно, и покупает систему ради «лучших практик». В такой ситуации описание требований крайне затруднительно.

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

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

Не следует забывать и о том, что бизнес не стоит на месте, для его развития требуются постоянные изменения, а описанные требования могут устареть прежде, чем будет разработано и внедрено ПО.

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

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

Компания BAA, управляющая большинством крупных аэропортов в Соединенном Королевстве, выяснила, что основная проблема, по которой при строительстве затягиваются сроки и превышается бюджет, состоит в том, что контракты пытаются переложить бóльшую часть рисков на подрядчиков. Поэтому при строительстве терминала 5 в аэропорте Хитроу была разработана особая форма контракта — так называемое соглашение Т5. По нему BAA брала весь риск проекта на себя, а подрядчики работали объединенными коллективами в небольших подпроектах с согласованной сметой и премиально-рисковым фондом. В случае, если стоимость подпроекта превосходила запланированные расходы, деньги для покрытия дополнительных затрат брались из премиально-рискового фонда. По завершении проекта средства из этих фондов были направлены на премирование рабочих групп.

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

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

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

Система розничного магазина отвечает за автоматизацию всех процессов, связанных с перемещением и учетом товара в розничных торговых точках (кроме бухгалтерского учета).

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

Таким образом, системная архитектура отражает долгосрочные и ключевые договоренности между заказчиком и исполнителем. Как правило, она фиксируется в виде небольшого (около 10-20 страниц) документа. Помимо текста он включает наглядные схемы — графические проекции модели системы. Для его составления требуются опыт и квалификация. Главное, чтобы ключевые участники процесса разработки понимали этот документ одинаково и могли общаться в его терминах.

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

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

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

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

___________

¹'Поппендик М. Бережливое производство программного обеспечения. От идеи до прибыли: Пер. с англ. — М.: Вильямс, 2010. — С. 218—219.

Репликация: База Знаний «Заказных Информ Систем» → «Системная архитектура»

Техники и проблемы пэкеджинга бизнес-приложений для Windows (Павел Воронов, ADD-2011)

2011-06-08T16:24:25Z

StasFomin:

Семинары и тренинги — Welcome!

2011-06-06T13:55:58Z

StasFomin:

Bad news, everyone! Предложение ниже временно отменяется — мы переезжаем.

Когда мы снова сможем проводить семинары на новом месте — пока неизвестно, вряд ли раньше нового года…

У вас есть сообщество и хотите провести семинар-тренинг-миниконференцию по темам близким к разработке ПО?

Можно у нас, в формате «после работы, бесплатно, +join us, we have cookies».

Преимущества:

Центр Москвы, в 7 минутах ходьбы от 5 станций метро.
Удобный зал для IT-презентаций — два больших экрана, все от них близко — можно показывать код, текст, мелкие детали, есть звук, Wi-Fi, электронный маркер и т.п.
- Вместимость порядка 80-100. (Набивалось и по 130, но это уже некомфортно).
Чай-кофе-плюшки всем и бесплатно.
По желанию — запись, монтаж и публикация видео (две камеры+скринкаст, см. http://vimeo.com/belonesox/videos, ну и вообще Категория:Открытые Семинары).
У нас собираются сообщества AgileRussia.ru, ALT.NET, UML2, Stratoplan.ru, MSTC, и др.

Темы — более-менее связанные с разработкой.

Программирование: языки, фреймворки, от унылого мейнстрима до безумно маргинальных.
Аналитика: от схоластики смурных диаграмм и моделей (UML/ARIS/…) до NLPшных техник охмурения заказчика.
Тестирование: от «атаки царя обезьян» до «программирования роботов».
Менеджмент: от бездушного управления по KPI, до Agile, лидерства и вовсе полного раздолбайства.
Юзабилити: от как «сделать красиво» до «к чорту красоту, сделайте удобно!».

Что-то забыл? — Предлагайте.

Вопросы, замечания, предложения → Стас Фомин.

Шишки инженера при переходе в стан менеджмента (Сергей Вербенко, 2011-05-17)

2011-06-06T13:51:27Z

StasFomin:

Докладчик: Сергей Вербенко

Как сотрудники «выгорают», что с этим делать и как это исправить (Педько Олег, 2011-05-17)

2011-06-06T08:30:10Z

StasFomin:

Докладчик: Педько Олег

О чем нужно обязательно подумать, развивая персонал (Михаил Заборов, 2011-05-17)

2011-06-06T08:26:04Z

MikhailZaborov: /* Презентация */

Докладчик: Михаил Заборов

Карьерная история — рост в одной компании и выход на карьерное плато (Александр Орлов, 2011-05-17)

2011-06-06T08:21:07Z

StasFomin:

Докладчик: Александр Орлов

Карьерная история — технология Джампер (Слава Панкратов, 2011-05-17)

2011-06-06T08:13:48Z

StasFomin:

Докладчик: Слава Панкратов

Эволюция Wiki-Way командной разработки/Презентация

2011-06-04T12:49:27Z

VitaliyFilippov:

Slide Show

Автор: Стас Фомин
Дополнительный нижний колонтитул: Стас Фомин, 17:53, 5 апреля 2012

Эволюция Wiki-Way командной разработки

Виталий Филиппов, Стас Фомин

CUSTIS

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

У нас она начиналась с идей:

Open-Source: нет жестких ограничений — гибкость и опыт масс в одном флаконе.
Wiki + баг-трекер + система контроля версий: достаточно для всего.
Правильная вики ⇒ MediaWiki: мэйнстрим + расширяемость.

Кроме того, мы (в конце 2010г) наконец-то выполнили обещание выйти в Open-Source и теперь существует проект 4intra.net («фор интранет», то есть, «для интранета»), который вы можете попробовать своими руками.

Например, расширяемость превращает MediaWiki не просто в базу знаний или инструмент документирования, а даёт возможность сделать такие нетривиальные «плюшки», как

система информационных потоков (читай — форумов и блогов),
презентаций,
опросов и экзаменов,
личный «кэш» сетевых закладок

и так далее.

Не говоря уже о расширенных медиа-возможностях — вставке изображений и видео, графов и графиков, UML и MindMap’ов, TeX и прочих «фичах».

О том, как мы пришли к своему выбору, почему он всё больше совпадает с мировой практикой, что представляют из себя все эти, а также многие другие вкусности, реализуемые с помощью MediaWiki, Bugzilla, SVN, ViewVC, FeedOnFeeds и так далее, и о том, куда двигаться дальше, и будет доклад.

KISS or my own time-management best practice (Антон Зотин, Stratoplan World, 2011-05-17)

2011-06-03T19:22:33Z

StasFomin:

Докладчик: Антон Зотин

Аспектно-ориентированное программирование. PostSharp. (семинар 2011-05-12, для студентов)

2011-06-03T11:14:42Z

StasFomin:

Java 3G: Groovy, Grails, Griffon (семинар 2011-05-26, для студентов)

2011-06-03T11:07:55Z

StasFomin:

AgileDays -2011:Отчет Заборова М.А.

2011-06-03T10:45:25Z

StasFomin: