Разработка программного обеспечения на заказ является основным видом деятельности компании Instream. Сотрудники компании добиваются выполнения обязательств по качеству и срокам благодаря отношению к работе и технологическому процессу.

Основы технологического процесса Instream исторически закладывались в службе разработки АО Вымпелком (Билайн), которую в 2001-2005 годах возглавлял Владимир Герман - основатель Instream. ИТ-руководством Вымпелкома была поставлена задача создать технологию разработки решений, способную поддержать растущий бизнес Билайн - обеспечить высокую скорость создания новых продуктов и одновременно с этим держать высокое качество обслуживания миллионов абонентов. В основу процесса были положены идеи Capability Maturity Model, Rational Unified Process и Extreme Programming. В течение 10 лет сначала в Вымпелкоме, а затем в Instream, процесс разработки программного обеспечения совершенствовался и продолжает совершенствоваться для лучшего удовлетворения запросов заказчиков по качеству, скорости создания и экономической эффективности.

Функциональный дизайн

Ключевым моментом разработки информационных систем является Функциональные Требования (ФТ). Для написания функциональных требований Instream использует и рекомендует использовать сценарии использования (use cases). В этом случае написанные требования легко читаются и наиболее просто отражают пожелания заказчика. Функциональные требования пишутся либо заказчиком самостоятельно, либо совместно с исполнителем. Написание функциональных требований очень полезно, и мы рекомендуем их писать до выбора компании-разработчика. Во-первых, при написании функциональных требований ярко проявится эффект аппетита, приходящего во время еды. Крайне желательно чтобы этот эффект проявился на ранних этапах проекта, когда он не может привести к срывам сроков и раздутию сметы по ходу работ. Во-вторых, если в создании информационной системы заинтересованы несколько служб компании-заказчика, то ключевые игроки на этапе написания ФТ отследят свои интересы и "утрясут" неизбежные противоречия. В-третьих, с написанными ФТ процесс выбора компании-разработчика будет более коротким по времени и менее рискованным, так как позволит разработчикам-кандидатам более оперативно и предметно оценить сроки и назвать стоимость работ.

Разработка ТЗ

На основе функциональных требований компания-разработчик разрабатывает Техническое Задание (ТЗ), которое также полезно писать на языке сценариев использования и обязательно на языке, понятном заказчику, несмотря на то, что это "техническое" задание. Как правило, ТЗ является основной спецификацией, прикладываемой к контракту, и если оно будет не понятно заказчику, то в дальнейшем практически неизбежны разочарования, когда после окончания всех работ и сдачи проекта выяснится, что заказчик не сможет использовать разработанное ПО. Если необходимо, то разработчики всегда могут написать для своего внутреннего использования другие технически углубленные спецификации. Отсутствие ТЗ, согласованного до того, как начнется разработка программного кода, является одним из опаснейших источником проблем, способным загубить проект в целом. На основе технического задания разработчики разрабатывают программное обеспечение, а тестировщики - тестовые сценарии. Очень важно чтобы тестовые сценарии были написаны на основе того, что написано в ФТ и ТЗ, а не на основе программных спецификаций, так как тесты должны проверить, насколько качественно выполнено задание заказчика, а не просто, работает ли программа. В случае сложной системы выполняется модульное тестирование, позволяющее снизить риски сборки системы из полуфабрикатов, и провести затем комплексное тестирование за минимальное количество времени и итераций.

Разработка ПО и тестирование

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

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

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