Ежегодные ISV-форумы — ключевые мероприятия в работе Oracle с компаниями-разработчиками. В последние годы их задачи менялись, отражая развитие партнерской сети. Так, основной целью первого ISV Forum в 2004 г. был рекрутинг партнеров, затем — миграция решений на Oracle, развитие бизнеса с вендором и расширение спектра его продуктов, используемых в разработках.
В нынешнем году программа Oracle ISV Forum изменилась кардинально — она была практически полностью сфокусирована на общих методиках, стратегиях и технологиях разработки ПО.
Почти половина всех партнеров вендора в России и СНГ — это ISV-компании, в СНГ их более 360. Рост продаж через ISV-канал в странах СНГ, по данным Oracle, превышает 30% в год. Наиболее яркий пример развития направления технологической поддержки компаний-разработчиков, считают в Oracle, — это открытие в ноябре 2007 г. в Москве Технологического центра для компаний-разработчиков (Oracle ISV Migration Center), третьего в регионе ЕМЕА и первого русскоязычного. Центр создан совместно с компаниями «Форс — Центр разработки» и Fujitsu Siemens Computers. Партнеры могут воспользоваться аппаратными, программными и экспертными ресурсами Центра для адаптации собственных разработок под новые версии и продукты Oracle, для перехода на Oracle с других технологических платформ, проведения комплексного тестирования и оценки своих решений.
Российские разработчики ПО, подчеркнул директор по технологиям «Oracle СНГ» Глеб Ладыженский, часто пытаются все сделать самостоятельно, в то время как их западные коллеги предпочитают максимально использовать в своих продуктах готовые «чужие» компоненты.
Помимо СУБД Oracle вендор хочет привлечь внимание российских ISV-партнеров к ряду других продуктов, полученных в результате стратегических приобретений. Это TimesTen — реляционная СУБД, оптимизированная для работы с оперативной памятью и целиком размещаемая в ней; Berkeley DB — встраиваемая СУБД с открытым кодом; Oracle Coherence — решение по кластеризации приложений из линейки связующего ПО (Fusion Middleware), повышающее устойчивость системы к сбоям благодаря резервированию данных на множестве узлов кластера.
Вниманию партнеров вендор представил также Oracle JDeveloper; Oracle Application Express; Oracle BPEL Process Manager (ядро интегрированного набора продуктов Oracle SOA Suite, исполнитель бизнес-процессов, описанных на языке проектирования бизнес-процессов BPEL, Business Process Execution Language); Oracle Identity & Access Management Suite (интегрированный набор средств управления идентификационными данными и доступом пользователей к корпоративным приложениям и информационным ресурсам).
Более 300 участников ISV-форума смогли получить рекомендации профессионалов по технологиям проектирования и разработки ПО, управлению качеством, методам организации заказной и тиражной разработки, созданию групп разработчиков и групп тестирования. Все эти темы оказались востребованными партнерами вендора. По мнению представителей ряда компаний, как небольших, так и крупных, сегодня методологическая поддержка Oracle так же важна, как и информация о ее продуктах.
В разработке тиражного ПО важную роль играет классификация пользователей и их потребностей, подчеркнула консультант-аналитик Евгения Владимирская. В числе основных особенностей тиражных продуктов — возможность их установки и обновления с минимальными затратами, многократная установка, причем разными пользователями, использование в разных условиях и в разных конфигурациях и др. Пользователей можно разделить на три группы — обычные (конечные), бизнес-пользователи (администраторы) и эксперты. Для конечных пользователей важны, в частности, удобный инсталлятор, простое руководство по установке (которое часто отсутствует), упрощенная установка заплат и обновлений, средства резервного копирования критических настроек при обновлении. Для бизнес-пользователя (администратора) — различные дистрибутивы (в зависимости от платформы/базового ПО) и процедуры установки, инсталлятор для конкретной платформы, информативная документация, плановые обновления и инструментарий по управлению процессом обновления, информация об ошибках и т. д.
Александр Самбук, директор Центра специальных разработок «Люксофт», рассказал об особенностях заказной разработки ПО как сферы услуг B2B. Он выделил четыре основные модели бизнеса в области заказной разработки.
Первая — стаффинг, когда исполнитель лишь предоставляет в распоряжение заказчика персонал и мало осведомлен о сути выполняемых им задач. Вторая схема — аутсорсинг на уровне технологических групп, когда область ответственности исполнителя ограничена определенной частью процесса разработки (обычно кодирование или тестирование). Третья модель — аутсорсинг на проектном уровне, когда исполнитель отвечает за полный цикл разработки ПО, бизнес-требования при этом могут описывать как заказчик, так и исполнитель, а последний может передавать работы далее, используя две предыдущие модели. Критерий успеха в таком проекте — успешное внедрение у заказчика разработанного «с нуля» программного решения. Четвертая, наиболее зрелая модель — консалтингово-внедренческая, где исполнитель отвечает за взаимную адаптацию бизнес-процессов заказчика и серийного гибко настраиваемого ПО.
Какая именно модель подойдет в каждом конкретном случае, зависит от степени участия исполнителя в принятии бизнес- и технологических решений — реализует ли он то, что диктует заказчик, участвует в разработке совместно с заказчиком или формулирует сам, а также степени его ответственности за качество разработки — низкой (исполнитель следует процессам, принятым у заказчика), средней (исполнитель предлагает внести улучшения в эти процессы, а также использует отдельные фрагменты собственных процессов), или высокой (исполнитель следует своим собственным процессам).
О методиках прогнозирования сроков и оценки трудозатрат рссказал Владислав Балин, директор по разработке компании Infra Telesystems. Оценки длительности проекта могут быть очень неточны, поскольку эксперты часто склонны к систематической недооценке сложности; наличие рисков значительно снижает точность оценок, а в случае единственной оценки нельзя понять, на что «заложился» давший ее эксперт. Поэтому предлагается давать оценки оптимистичного и пессимистичного сценариев по методу PERT Estimation, учитывающему три экспертные оценки срока: L — «раньше точно не справлюсь, даже если повезет»; H — «успею гарантированно, даже с учетом всех имеющихся рисков»; M — «наиболее вероятно, что успею». Чем больше в проекте доля «независимых» задач, тем точнее суммарная оценка сроков.
Также эксперт рассказал о метриках «продуктивности», используемых при наличии корелляции «время — объем». Такие показатели более стабильны на больших отрезках времени, в том числе и для групп программистов. При этом «продуктивность» нельзя применять как показатель эффективности работы. Например, программист, тратящий меньше времени на проектирование и пишущий больше кода, покажет более высокую «продуктивность». А для двух задач, одна из которых сложнее другой, «продуктивность» решения более сложной должна быть меньше.
Немало подводных камней таит стадия тестирования разработанного ПО. По мнению Андрея Сикорского, сотрудника компании UsabilityLab, к числу наиболее распространенных относятся отсутствие базы знаний, нечеткое понимание командой тестеров того, что именно считать дефектами, пренебрежение оценками качества и качеством оценок и слишком позднее начало тестирования. При этом на каждом этапе возможны свои промахи. Так, при планировании — неправильное определение рисков, излишний фокус на функциональном тестировании, откладывание нагрузочных тестов на последний момент. Тестирование нередко считают занятием для начинающих или «неудавшихся» программистов, однако тестер должен быть специалистом в предметной области — лучше хорошо тестировать, чем неважно программировать. В то же время неправильно и считать, что «программисты не должны тестировать», так как не все может быть протестировано тестерами, и кто, как не программист, лучше знает свой код?
В нескольких докладах речь шла о контроле качества разработки ПО. Типичные проблемы таких проектов — срывы договоренностей, неожиданные осложнения в самом конце проекта, задержка поставки и увеличение стоимости, отсутствие предсказуемого результата. А низкое качество — это необходимость переработки значительной части кода, ошибки в функциональности, жалобы пользователей. В качестве инструмента повышения качества разработки предлагается методология CMMI (Capability Maturity Model Integration). При грамотном применении она позволяет повысить управляемость и прозрачность проектов разработки ПО и устранить многие типичные ошибки.