Версия для слабовидящих
Из всего многообразия разрабатываемых программ две трети так и не добираются до конечного пользователя. Среди тех проектов, которые всё-таки достигли этапа внедрения более половины вышли за рамки изначального бюджета и сроков реализации. Почему так происходит? Существует множество возможных причин провала проекта. Среди них неверная оценка затрат, некорректно поставленная цель разработки, слабый менеджмент, поражение в конкурентной борьбе, и многие другие.
ООО НПО «RBS» занимается разработкой ПО с 2007 года. За прошедшее время нам довелось работать над множеством различных проектов, и, конечно, мы тоже столкнулись со всеми типичными проблемами доведения ПО до конечного пользователя. Однако, нам всегда удавалось завершить каждый проект, за который мы брались. Сто процентов программного обеспечения, разрабатываемого внутри нашей компании было внедрено у клиента, с последующей технической поддержкой и дальнейшим развитием. В этой статьей мы расскажем, как разрабатывается ПО в компании RBS.
СОДЕРЖАНИЕ
Для чего мы разрабатываем программы?
Ответим на вопрос: «Для чего мы разрабатываем программы?» Для нас это способ заработка, творческого самопроявления, профессиональной самореализации. Программирование - это дело всей нашей жизни. Но мы всегда помним, что главной причиной, по которой мы занимаемся созданием программных продуктов является потребность в них конечных пользователей. Именно пользовательский спрос, наличие у клиента задач, которые необходимо решить техническими средствами, определяет наш подход и отношение к ремеслу. Это заставляет разработчика ориентироваться на результат и принимать решения, только в случае уверенности, что эти решения помогут достигнуть результата - создать инструмент решения конкретной пользовательской задачи таким образом, чтобы он полностью соответствовал потребностям и пожеланиям пользователя. То есть методология разработки ПО должна быть в наибольшей степени зависима именно от фактора результативности выбранных подходов и инструментов, под результатом подразумевая успешное завершение проекта.
Ознакомится с проектами нашей компании Вы сможете перейдя по ссылке «Наши продукты».
Этап планирования программного продукта
С какими сложностями сталкиваются разработчики в процессе решения полученной от клиента задачи? Во-первых, изначально никакой задачи не существует, во всяком случае в достаточно понятном для разработчика виде. Разработчику еще предстоит провести анализ пожеланий и требований заказчика, и превратить их в техническое задание. Во-вторых, разработчик не имеет знаний о той предметной области, которую предстоит автоматизировать, что означает потребность в её анализе и изучении. То есть, нужно понимать, что до начала разработки, необходимо проанализировать область деятельности клиента, понять его пожелания, и сформулировать цель создания программного проекта, определив крупными штрихами задачи, которые необходимо решить для достижения этой цели. Это называется этапом планирования проекта, и основная роль на этом этапе отводится специалистам по системной аналитике и менеджерам проекта, главная задача которых совместно с клиентом сформировать техническое задание.
Не стоит забывать о естественных ограничениях проекта - времени и бюджете. Они значительно влияют на задачи, которые будут поставлены отделу разработки, ведь разработчику необходимо не просто написать программу, но при этом уложиться в сроки и желательно не выйти за рамки бюджета, а значит где-то, возможно, проект необходимо немного упростить в пользу более важного функционала. Как Вы могли уже понять, на этапе планирования крайне важно определить приоритет реализации каждой функциональной возможности (варианта использования) приложения, задекларированной в техническом задании. Этот приоритет будет учтен при определении очередности реализации функционала.
Исполнитель заданных проектных работ готовит проектную документацию ровно в том объеме, который требуется для проектируемого функционала и соответствующего проектного решения. Например, для определения всей архитектуры системы часто требуются схемы информационных потоков, модели данных, диаграмма вариантов использования, концептуальная модель и так далее. А для отдельно взятой функциональной возможности может потребоваться только набросок графического интерфейса от руки. В общем-то, проектная документация должна отвечать на вопрос “как это работает”, но без избыточности. На старте проектирование наибольшую ценность представляют модели бизнес-процессов, которые предстоит автоматизировать. Они дают понимание задач, которые встают перед разработчиками, и определяют дальнейший вектор развития проекта.
Реализация программного продукта
После того, как группа архитекторов определила концепт системы, архитектурные стратегии, интерфейсы подсистем, схемы взаимодействия, и другие фундаментальные особенности, для проекта начинается этап разработки, то есть фаза активной реализации приложения и его функциональных возможностей. На этом этапе справедливы несколько принципов, призванных обеспечить результативность работ по разработке. Например, после создания каркаса приложения и его системного функционала, и перехода к реализации пользовательского функционала, мы стремимся к как можно более частому выпуску сборок версий ПО. На ранних этапах сборка и передача ПО на тестирование или клиенту выполняется раз в две недели, на более поздних, ближе к сдаче проекта, сборка осуществляется ежедневно по мере реализации функциональных возможностей. Это дает нам быструю обратную связь. Клиент раньше получает версию программного продукта, пусть и “сырую”, но он сразу может найти некоторые фундаментальные ошибки или недостатки в нашем понимании задачи, и сообщить нам о них. А это позволяет нам оперативно отреагировать на замечания и сразу же внести изменения в концепт, проектные решения, или реализацию. Время - это наш ценнейший ресурс, а скорость реакции - важнейший инструмент достижения результата.
Так как мы пишем программы конкретно для клиента, для решения его повседневных задач, мы обязаны подумать о том, как будет развернуто приложение у пользователя, причем подумать в самом начале проектирования. Инсталляция и обновление проектного продукта - это тоже одна из важнейших архитектурных стратегий. Определив её, ближе к выпуску финальной версии становится актуальной задача реализация утилит, предназначенных для установки и обновления. Задача усложняется тем, что большинство программных продуктов - это не маленькие утилиты, а многоуровневые системы, состоящие из множества компонентов. То есть, например, утилита обновления сама по себе становится большим и самостоятельным приложением, с собственными функциональными возможностями, проектными решениями и задачами: от обновления базы данных, до обновления исполняемых модулей системы.
Первыми испытателями утилит установки и обновления становятся наши специалиста отдела технической поддержки и тестирования. Все сборки версий программных продуктов проходят через них, и они, фактически, воспроизводят те же действия, которые будет выполнять клиент, когда готовая версия продукта будет внедряться у него. Это позволяет нам самим почувствовать качество готового продукта, и определить задачи, которые еще предстоит решить, чтобы это качество улучшить, избавив проект от очевидных ошибок и неудобств. В случае провала тестирования версия возвращается на доработку, и разработчики, решив задачи на исправление, готовят следующую сборку.
Как видно, в процессе разработки программного продукта много элементов, которые повторяются снова и снова, до достижения удовлетворительного результата. Это и итерации проектных работ, и итерации реализации функционала. Частая повторяемость действий дает нам нужную гибкость при создании продукта, ориентированного на его конечных пользователей. Обратная связь с пользователями после выпуска и внедрения версий позволяет быстро вносить необходимые изменения в проект. Это, а также мотивированная команда, нацеленная на результат, обеспечивает нашей компании фантастические сто процентов успешно внедренных программных продуктов.
Ознакомится с продуктами нашей компании Вы сможете перейдя по ссылке «Наши продукты»