Разработка программного обеспечения

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

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

Разработка ПО

СОДЕРЖАНИЕ

Для чего мы разрабатываем программы?

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

Ознакомится с проектами нашей компании Вы сможете перейдя по ссылке «Наши продукты».

Этап планирования программного продукта

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

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

Планирование программного продукта

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

Этап проектирования программного продукта

Определение концепта разрабатываемого ПО

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

На самом деле, в RBS нет выделенного архитектора проектов. В последнее время мы применяем подход, который раз за разом дает нам весьма убедительные проектные решения. Он заключается в следующих принципах: проектные работы выполняются группой архитекторов, в который входят инициативные сотрудники, склонные к решению подобных задач, причем без оглядки на стаж или должность, от директора до стажера. Это дает нужную широту мнений и идей при обсуждении проектных решений. Следующая важнейшая принципиальная особенность заключается в том, что любые проектные решения должны пройти этап защиты и согласования, прежде чем будут приняты. То есть если, скажем, тимлид проектной группы, входящий в группу архитекторов, предложил вариант реализации авторизации в приложении, то он обязан собрать “совет” архитекторов, где должен будет ответить на любые вопросы оппонентов, описать, как именно его проектное решение будет работать в предлагаемых вариантах использования ПО, и убедить остальных в жизнеспособности предложенной идеи, и ее соответствии требованиям к программному продукту. В случае, если инициатор провалил защиту, он проводит дополнительные проектные работы, и через некоторое время снова собирает группу архитекторов на повторную защиту. Такой подход гарантирует, что к разработчикам попадет проектное решение, которое учитывает большинство ситуаций, которые могут возникнуть при эксплуатации программы.

Проектирование программного продукта

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

Реализация программного продукта

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

Реализация программного продукта

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

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

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

Ознакомится с продуктами нашей компании Вы сможете перейдя по ссылке «Наши продукты»

Яндекс.Метрика