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

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

2011-06-10T11:26:47Z

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

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

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

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

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

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

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

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

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

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

Репликация: База Знаний «Заказных Информ Систем» → «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:

Максим Цепков - AgileDays-2011

2011-06-02T16:58:30Z

StasFomin:

Автор отзыва

AgileDays-2011:Отчет Цыганкова Д.А.

2011-06-02T13:47:45Z

StasFomin: /* Lightning Talk */

Автор отчета

AgileDays-2011: Отчет Кудрявцева В.Б

2011-06-02T13:45:27Z

StasFomin:

Автор отчета

AgileDays-2011: Отчет Беликова Сергея

2011-06-02T13:40:58Z

StasFomin:

AgileDays-2011:Отчет Никитина В.В.

2011-06-02T13:27:03Z

StasFomin:

В целом конференция понравилась: место, инфраструктура, организация. Были, конечно, и недочеты, но их я уже записал в опросник организаторов. Очень порадовали два доклада и два тренинга Сергея Дмитриева (Норвегия) и Тимофея Евграшина (Украина) (о них скажу ниже).

Для меня основной положительной мыслью, которую я еще раз освежил в памяти, была такая: нам надо наращивать agile'вскую гибкость, самоорганизацию и взаимное доверие в командах.

AgileDays-2011: Отчет Гребнева Н.Ю.

2011-06-02T13:23:23Z

StasFomin: /* Lighting talk */

Автор отчета

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

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

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

Далее подробно по каждому докладу.

Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011)

2011-05-27T18:43:18Z

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

Реализация Recommendation Engine средствами MS SQL (Глеб Луцков, ADD-2011)

2011-05-27T18:39:05Z

StasFomin:

Вымирают ли клиентские приложения? Браузер против клиента! (Роман Здебский, ADD-2011)

2011-05-26T15:29:26Z

StasFomin:

Системная архитектура вместо требований (семинар 2011-03-22, preview ReqLabs-2011)

2011-05-26T14:46:29Z

StasFomin:

Докладчик: Михаил Заборов
Дата: 22 марта 2011

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

2011-05-26T14:43:07Z

StasFomin:

Как сделать интернет-сайт на SharePoint и не передумать на полпути (Владимир Колесников, ADD-2011)

2011-05-26T14:41:51Z

StasFomin:

Разработка приложений с использованием Windows Workflow Foundation (Максим Игнатов, ADD-2011)

2011-05-25T15:27:19Z

StasFomin:

MongoDB (Сергей Туленцев, ADD-2011)

2011-05-25T09:39:20Z

StasFomin:

NoSQL-практикум: Промышленная автоматизированая измерительная система на CouchDB (Артур Орлов, ADD-2011)

2011-05-25T09:38:11Z

StasFomin:

Мобильная веб-разработка (Андрей Ребров, ADD-2011)

2011-05-25T09:17:13Z

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

Эффективная разработка бизнес-приложений на Silverlight и WPF (Александр Онуфриев, ADD-2011)

2011-05-23T15:00:27Z

StasFomin:

Увеличиваем производительность MySQL в десятки раз используя HandlerSocket (Александр Календарев, ADD-2011)

2011-05-23T14:38:21Z

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

Пример разработки высоконагруженной реляционной базы данных (Павел Белоусов, ADD-2011)

2011-05-23T14:32:52Z

StasFomin:

Построение 3D модели сцены по одному фотоснимку (Дмитрий Вихарев, ADD-2011)

2011-05-23T14:31:36Z

StasFomin:

Первый опыт внедрения WPF в сложной системе (С++ и COM) (Михаил Павлов, ADD-2011)

2011-05-23T14:29:36Z

StasFomin:

Nemerle Deep Dive (встреча ALT.NET, 2011-03-31)

2011-05-23T13:18:27Z

StasFomin:

Доклад: ~~"Nemerle must die"~~ «Nemerle deep dive» («Глубокое погружение в Nemerle»).

Докладчик: Чистяков Владислав, текущий maintainer, архитектор и идеолог языка Nemerle.

Рассказ о языке:

Ядро языка;

Вывод типов;

Мимикрия под C# в области поддержки ООП;

Поддержка функционального программирования:
Функции как первоклассные значения;

Алгебраические типы;

Сопоставление с образцом;

Гигиенические (LISP) макросы в Nemerle:
Что такое? С чем едят?

Как сочетаются с IDE и прочими технологиями?

Сложности разработки, отладки, сопровождения.

Развечание мифов;

Ограничения версии 1.0;

Что будет в Nemerle 2.0?

Примеры практического использования макросов, прикладные макро-библиотеки:
Nemerle.Xml — XML-литералы;

Nemerle.Peg — быстрый и гибкий генератор парсеров шаговой доступности;

ComputationExpressions:
Асинхронное программирование;

Yield внутри выражения;

Другие применнения.

Nemerle on Rails — миграции, автоматизация формирования ViewModel, движок рендеренга HTML «Spark»;

Nemerle.WUI.Reactive — реактивный Web-интерфейс на основе статически типизированного языка вместо скриптов;

Мелкие полезняшки:
Автоматизация реализации зависимых свойств в WPF

Record — автоматизация создания конструкторов

Автоматизация паттернов проектирования ООП (Abstract factory, Aggregate, Proxy, Singleton)

Late-binding — позднее связывание

Surroundwith — создание аналогов using и lock в мгновение ока.

Memoize

$-строки

Assertions

ListComprehension

Regexp match

StructuralEquality, LexicographicCompareTo, StructuralHashCode

.. и многое другое.

Nemerle.Peg — .NET генератор парсеров шаговой доступности (Денис Рысцов, ADD-2011)

2011-05-21T05:27:03Z

StasFomin:

«70% чего?» или различные метрики измерения тестового покрытия (Дмитрий Фазуненко, ADD-2011)

2011-05-21T05:26:38Z

StasFomin:

Object XPath Navigator (Андрей Майоров, ADD-2011)

2011-05-21T03:51:31Z

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

Заднее чутье разработчика, или как избежать проблем эксплуатации? (Антон Белоусов, ADD-2011)

2011-05-20T10:49:46Z

StasFomin:

Фриланс — будущее IT-разработки (уже наступило?) (Стас Давыдов, ADD-2011)

2011-05-20T10:49:40Z

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

ADD 2011: Отчёт Русецкого Георгия

2011-05-19T20:15:02Z

StasFomin: /* Nemerle.Peg — .NET генератор парсеров шаговой доступности */

Конференция проводилась 29-30 апреля 2011 в Санкт-Петербурге.

Гостиница (бизнес-отель «Карелия»): Весьма неплохая (на фоне отстойной гостинице в Ярославле, где проводилась ADD-2010, просто отличная). Правда, обещанный WiFi работал только в холле гостиницы, в номере не работал.

Организация: Общее впечатление: организовано на хорошем уровне, доклады читались в трёх секциях, места всем хватало (единственно — секция B располагалась в переходе между зданиями, не очень удобный зал). Обеды, кофе-брейки также без нареканий — всё на уровне. А вот качество докладов, на мой взгляд, хуже, чем на предыдущей конференции ADD.

Оптимизация LAMP-приложения на примере OpenX: разгоняемся до 1000 запросов в секунду (Александр Чистяков, ADD-2011)

2011-05-18T09:48:52Z

StasFomin:

Разработка программного обеспечения для маленьких (ADD-2011, Яков Сироткин)

2011-05-18T09:47:48Z

StasFomin:

ADD 2011: Отчет Василия Маслова

2011-05-18T08:10:14Z

StasFomin: /* Nemerle Deep Dive */

Максим Цепков - отчет об ADD-2011

2011-05-18T08:08:52Z

StasFomin:

В статье Максим Цепков - отчет об ADD-2011/Заметки по докладам - полные заметки, которые я делал на конференции - сохранил для себя

Максим Цепков - отчет об ADD-2011/Разработка программного обеспечения для маленьких

2011-05-17T17:26:04Z

StasFomin:

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

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

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

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

ADD 2011: Отчёт Русецкого Георгия/Взаимоотношения заказчика и исполнителя на проекте

2011-05-17T16:17:05Z

StasFomin: Новая страница: «[[Взаимоотношения заказчика и исполнителя на проекте (Дмитрий Завалишин, ADD-2011)|Большой рас...»

Большой рассказ про взаимоотношения заказчика и исполнителя в сфере разработки ПО, богато украшенный примерами из жизни.

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

Цель разработчика — сделать заказчика счастливым за определённые срок и бюджет (при этом, как ни странно, не столь важна реализованная функциональность).

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

Кто клиент? А кто будет пользоваться? Часто это разные люди
Есть ли у него опыт заказной разработки?
Кто платит, кто ставит задачу, кто проверяет
Понимает ли он, зачем ему это?

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

Vision — идея проекта (1 страница)
Требования (формируются в начале работы, страниц на 100, необходимо провести review с разработчиками и заказчиком), а также эскизы и use-cases.
Тест-план. По признанию докладчика, они сами обычно его не делают, если требования прописаны детально
План проекта
Deployment — диаграмма (чтобы не было проблем за день до сдачи, когда выясниться, что написанный софт не ставиться на оборудование заказчика)

Для контроля процесса разработки применяются различные инструменты. Некоторые из них, которые применяются в компании докладчика:

Трекинг прогресса разработки. Два прогресс-бара, один показывает готовность проекта по плану, другой — расход бюджета.
Регулярные релизы, ревью с клиентом
Сперва сделать вчерне всё, поскольку 30 % окажется не нужно, и нет риска застрять на полировке какой-нибудь фичи.

Если клиент не верит в предъявленные трудозатраты, можно:

Показать внутреннюю отчётность
Показать багтрекер
Распечатать код — по утверждению докладчика, он однажды так и поступил ;)

Что касается вопросов применяемой архитектуры и компонентов:

Знакомый инструментарий лучше, поскольку всё новое — непредсказуемо
Готовый сторонний код снижает стоимость и увеличивает риски
Повторное использование компонентов. Велика вероятность, что клиенту подойдёт ранее разработанное решение (его часть)
Интеграция с существующими системами — огромный риск

Сделать больше, чем просили — напрашиваться на проблемы. Особенно этого не любят западные заказчики («зачем вы сделали, то, что мы не просили, и кто за это заплатит?»)

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

Mac AppStore - спасение небольших разработчиков под Мак? (Сергей Кудряшов, ADD-2011)

2011-05-17T16:05:12Z

StasFomin: /* Примечания и отзывы */

Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011)

2011-05-17T15:59:27Z

StasFomin:

Максим Цепков - отчет об ADD-2011/Пример разработки высоконагруженной реляционной базы данных

2011-05-17T13:36:03Z

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

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

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

Механизмы, упомянутые в докладе.

Избегание tablock
Чтобы избегать deadlock — стройте обработку с циклом по одному индексу.
Учите матчасть — индексы, блокировки, планы выполнения.