Новая жизнь для устаревшего приложения: решение проблем при недостатке знаний о продукте

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

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

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

Высокий уровень образования наших инженеров и хорошо налаженные процессы обмена  знаниями в компании помогают нашим разработчикам решать проблемы “отсутствующих данных”, применяя методы обратной разработки (естественно, используя лицензии наших заказчиков). Четко сформулированные планы коммуникаций, проведение вводных семинаров и тренингов на стороне заказчика,  постоянный координатор проекта он-сайт у клиента (для команд численностью от 5-10 человек), регулярный процесс обмена комментариями и предложениями между командами являются ключевыми факторами успеха, позволяющими избежать проблем, вызванных человеческим фактором.

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

  • Наша компания отвечала за полную разработку программного обеспечения для нового монитора пациента, предназначенного для реализации на развивающихся рынках. В начале проекта заказчик ожидал, что наши инженеры будут использовать одну из уже имеющихся в линейке моделей мониторов в качестве прототипа для нового разрабатываемого продукта. Отсутствие экспертов и документации на стороне заказчика потребовали от команды Ауриги выполнения обратной разработки параллельно с портированием на другую платформу. Очень жесткие сроки и решение Заказчика сменить аппаратную платформу в ходе процесса еще больше усложнили проект. На основе кода старого продукта, нашими инженерами создавался абсолютно новый с переходом на более современную аппаратную и программную платформу. Разработка нового приложения началась сразу после успешной демонстрации работающего прототипа Заказчику. На основе тестирования производительности и исследований, проведенных Ауригой, в качестве целевой ОС была выбрана Embedded Linux. В настоящее время готовится первый релиз решения.
  • Инженеры Ауриги получили задачу по существенному расширению функционала для старого приложения Blackberry. Приложение насчитывало некоторое количество ошибок и испытывало существенные проблемы с производительностью. Предоставление новой жизни продукту осложнялось пробелами в документации и утратой всех ключевых экспертов. Нашим инженерам пришлось собирать информацию из различных источников буквально по крупицам. За три месяца команда Ауриги исправила большое количество проблем, провела рефакторинг кода,  изменила архитектуру, повысила производительность и стабильность приложения, а также добавила большое количество новых функций. Наличие координатора на стороне заказчика и использование методологии SCRUM с длительностью спринта в 2 недели позволили контролировать фактический процесс разработки и своевременно реализовывать необходимые изменения.
  • Аурига осуществила модернизацию встроенного программного обеспечения для компактных метеостанций. Решение представляет собой аппаратное устройство со встроенной ОС на базе процессора Blackfin. В начале проекта у заказчика было несколько версий продукта с многочисленными ошибками и проблемами конфигурации. Наши задачи включали унификацию конфигурации микропрограммного обеспечения в целях создания единой конфигурации для всех метеостанций, исправление программных ошибок синхронизации потоков, необходимых для обработки данных датчиков, сетевых соединений и т.д. При этом проект необходимо было выполнить быстро при отсутствии ключевых экспертов, обладающих соответствующим знанием продукта. Проект выполнялся с использованием методологии SCRUM с длительностью спринта 2 недели. В настоящее время наши разработчики проводят исследование для выбора оптимальной операционной системы, новой аппаратной платформы и технических средств для реализации последующей миграции.
  • Наш Заказчик – американская энергосберегающая компания – поставил Ауриге задачу по модернизации существующего программного решения для настольных рабочих станций и его портирования на новую веб-платформу. Продукт представлял собой набор различных версий приложений (всего около 25), включающих как внутренние клиентские базы данных, так и инструменты для расчета эффективности энергосбережения. Сначала нашим инженерам пришлось выполнять реверс инжиниринг алгоритмов, т.е. с языка кода составлять описание алгоритма и разбираться как и зачем оно так было сделано.  Затем код модифицировался для исправления существующих ошибок приложения.  Помимо, собственно, кодирования нашим специалистам необходимо было вникнуть в довольно сложную логику расчетов, связанных с энергосбережением. На последнем этапе разработки разработчики сконцентрировали внимание на модернизации возможностей системы по обеспечению безопасности при переносе всех функциональных возможностей на веб-платформу. Основной сложностью стал поиск экспертов для устаревшего приложения, разрабатывавшегося разными командами в течение последних 10 лет. Для совершенствования производительности решения было реализовано автоматическое тестирование – иначе срок решения этой задачи был бы слишком большим, а качество нужно обеспечить высокое. И все это практически в режиме реального времени – ведь приложением пользуются сотни людей ежедневно.