Исследование влияния организационно-технологических факторов на выбор и адаптацию методологии разработки программного обеспечения

Селявка К.В.
Выпускник группы ITM-013
Школа IT-менеджмента
РАНХиГС при Президенте РФ

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

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

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

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

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

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

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

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

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

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

Для того, чтобы определиться с оптимальной моделью разработки нужно выполнить последовательность операций. Подбор модели следует начинать с анализа текущей, уже используемой в компании методологии. До начала исследования полезно графически изобразить карту процесса разработки. Тогда, на первом этапе будет необходимо на карте процесса выделить элементы известных методик. Это необходимо для понимания причин заявленных к решению задач оптимизации цикла разработки программного обеспечения. Затем следует проанализировать связи между используемыми методологиями на разных этапах процесса разработки, и заявленными к решению задачами. Если корреляция присутствует, то влияние негативных факторов «вредных» в данном случае методологий, следует исключить или уменьшить, путем полного удаления или сокращения числа элементов, относящихся к определенным методологиям в карте процесса разработки программного обеспечения, и введения или добавления необходимого числа элементов с требуемыми характеристиками, в карту процесса. При этом важно вносить изменения в той временной части процесса, где необходима корректировка. По окончании моделирования процесса рекомендуется повторно графически отобразить полученную карту процесса, на предмет анализа избыточных действий, которые могут появиться за счет комбинирования приемов из различных методологий. В качестве общего приема для сокращения сроков разработки можно предложить метод «распараллеливания» этапов, т.е. те операции, которые можно выполнять параллельно, не следует делать последовательно. При этом платой, в прямом смысле слова, за сокращение сроков в данном случае станет увеличение трудозатрат. Также, если два или более элементов можно объединить в одну операцию, то от этого также не стоит отказываться. К примеру, объедение двух однородных комитетов в один расширенный, даст выигрыш времени, естественно, что при этом будет минус – участникам комитетов потребуется больше времени. Адаптацию разработанной модели нужно проводить учитывая особенности конкретного предприятия. Общим правилом здесь может стать принцип внесения в процедуру разработки минимально возможных изменений за одну итерацию. Что позволит более точечно реагировать на нежелательные последствия изменений и снизит дискомфорт от переходного процесса как для разработчиков, так и для пользователей программного продукта. В случае, если в компании используются элементы традиционных, классических методологий, в целях улучшения параметров может оказаться полезным ввести элементы современных, гибких, при этом не обязательно агрессивных методологий. Полезным может оказаться использование приемов хоть и гибкой, но совсем не агрессивной, широко известной «бережливой» методологии разработки программного обеспечения.