Алеш Живкович — специалист в области Computer Science, приглашенный профессор Университета Иннополис. Его научные интересы касаются метрики программного обеспечения и методов прогнозирования ошибок ПО. Мы побеседовали с профессором Живковичем об актуальных трендах в области разработки программного обеспечения и влиянии науки на эту сферу.

— Что входит в процесс разработки программного обеспечения? Какие у этого процесса стадии и какие специалисты в него обычно вовлечены?

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

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

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

— Насколько сильно изменились подходы к развитию программного обеспечения за последние десятилетия?

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

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

Есть много историй, подобных этой, когда под маской «гибкой методологии» оказывается профессиональная незрелость и программирование ad-hoc. Плоха ли методология гибкой разработки? Нет. Всегда ли она работает? Разумеется, нет. Есть много других методологий, отталкивающихся от характеристик самого проекта, — например, IBM RUP, Microsoft MSF или ACDM, разработанный в Университете Карнеги — Меллон, где я работаю.

— В чем отличие процесса разработки программного обеспечения сегодня по сравнению с 30-летней давностью?

— Скорее всего, скоростью размещения на рынке. Нам нужны быстрые результаты. Быстро — это три месяца, месяц или даже неделя. С появлением мобильных платформ и интернет-сервисов модель размещения сильно изменилась. Раньше были CD-диски или даже дискеты, теперь пользователь загружает программу из интернета и устанавливает ее.

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

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

— Какие новые методы создания программного обеспечения появились?

— В области разработки программного обеспечения появилось не так уж много новых методов. Появились некоторые интересные концепты, такие как уже распространенные SCRUM, DevOps и непрерывная интеграция, которая превращает разработку в разных часовых поясах в преимущество. Также популярно развитие новых идей через Hack Days, краудсорсинг/краудфандинг и стартапы. Быстро развивается и сообщество открытого программного обеспечения (Open Source).

Рекомендуем по этой теме:
6283
Внутренняя разработка в Computer Science

С другой стороны, есть много перспективных технологий и стратегических трендов, таких как интернет вещей (IoT), разработка на «третьей платформе» (Third Platform), концепция проектирования систем для гибридного облака (hybrid cloud) и так далее. Эти концепции могут повлиять на методы и подходы к разработке программного обеспечения в будущем.

— Какие факторы оказывают влияние на скорость разработки программного обеспечения?

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

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

Мне кажется, есть большая проблема, связанная с поставщиками услуг, так как покупатели не в курсе скрытых проблем. Соглашения об уровне предоставления услуги (Service Level Agreements) определены нечетко, и бизнес подвергается крупному риску, особенно малый и средний бизнес.

— Как наука повлияла на методы создания программного обеспечения?

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

— Заметно ли влияние массовых открытых онлайн-курсов на процессы, происходящие в сфере разработок программного обеспечения? Что вы думаете о перспективах подобных онлайн-курсов в целом?

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

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

Есть и более сложные темы и навыки, которые даются учащимся труднее. Например, студенты нашей программы MSIT-SE в Университете Иннополис могут овладеть целым набором навыков, которые требуются для участия в разработке в качестве архитектора программного обеспечения, менеджера проектов, тим-лидера или агента изменений в компании. Этот набор включает в себя коммуникативные навыки, критическое мышление, командную работу, тайм-менеджмент, принятие верных решений и так далее. Такие вещи очень сложно реализовать в онлайн-курсах, хотя и возможно.

— Можете назвать интересные исследования в области IT, которые вы недавно читали?

— Есть много интересных исследований. Я использую Science Direct в качестве ресурса для моих научно-исследовательских работ. Недавно я читал исследования, связанные с прогнозированием ошибок программного обеспечения, так как я пишу статью об использовании количественных показателей в прогнозировании ошибок программного обеспечения. Одна из научных работ описывает квазиэксперимент, который проводился в одном из словенских предприятий, разрабатывающем ERP на платформе Microsoft. Также я был рецензентом доклада в журнале Computers о том, как использовать измерения программного обеспечения для построения моделей прогнозирования ошибок. Другая работа, которую я читал как рецензент журнала Journal of Software: Evolution and Process, была о влиянии количества человек в команде на разработку программного обеспечения.

— Как, на ваш взгляд, научные исследования повлияют на разработку программного обеспечения в ближайшем будущем?

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