Сфера разработки программного обеспечения (ПО) – одна из самых активно развивающихся в настоящее время. В области разработки программного обеспечения на данный момент задействовано около 19 миллионов инженеров.
Результативное и успешное управление проектами разработки программного обеспечения обусловлено качеством и эффективной организацией работ в условиях ограничения стоимости и времени.
Согласно открытым данным исследований группы Standish Group в 2016 г., из 50 тысяч изученных программных проектов по всему миру, по причине неэффективного управления 19 % оказались провальными, 52 % спорными, что потребовало дополнительных вложений финансов и затрат времени и только 29 % проектов оказались успешными. По данным этого же исследования, бюджет проектов превышается на 179 %, а затраченное время на 202 % превышает изначально рассчитанное. Наряду с этим, реализуется в среднем всего 68 % объявленной в спецификации функциональности. Результаты исследования графически показаны на рис. 1.
Рис. 1. Диаграмма результатов данных исследований Standish Group
Вышеописанная ситуация объясняется тем, что разработка программного обеспечения является концептуально сложной деятельностью. Вместе с тем за последние 10 лет разработаны множество новых моделей управления разработкой программного обеспечения, которые допускают повышение эффективности управления, несмотря на невозможность значительного прорыва в области управления программными проектами.
Существующие системы управления ресурсами рассчитаны на контролирование проектами на стадии их реализации и применяются изначально для разрешения таких необходимых задач, как [5]:
– представление общих норм проекта;
– представление логической организации работ, многоуровневого описания проекта;
– установление объединенного организационного состава исполнителей, имеющихся средств и перечня материалов;
– подготовка плана проекта, представленного в виде перечисления совокупности работ, связанных без учета ограниченности средств;
– регулирование плана проекта с учетом ограниченности средств;
– установление кризисного плана и запаса времени исполнения работ проекта;
– установление требований к проекту в финансировании, ресурсах и техническом обеспечении;
– подготовка плана разделения во времени загрузки восстановляемых ресурсов;
– оценка вероятности рисков и проектирование расписания с учетом рисков;
– извлечение, подборка и обобщение работ по срокам, средствам, видам и т.д.;
– введение фактических показателей состояния решения поставленных задач, объемов выполненных работ и применения средств;
– оценка несоответствия в порядке выполнения работ от поставленного плана и прогнозирование основных норм проекта в будущем;
– наглядное изображение хода выполнения работ проекта в виде схем, диаграмм и т.д., предоставление отчетов, необходимых для прогнозирования, планирования и проверки;
– объединение системы управления проектами в корпоративные управленческие системы.
Выбор необходимой системы управления обуславливается такими критериями, как [6]:
– объемом и затруднительностью проекта (объем работ, средств, времени, календарей);
– необходимый объем организованных порядков работ;
– обязательность объединенной работы над проектами и потенциал обмена информацией через Internet;
– потребность ввода и вывода данных из других систем и баз данных;
– потребность исполнения расчетов по формулам, заданным пользователем;
– потребность планирования средств между несколькими проектами, учитывая приоритет проекта;
– простота овладения и практичность графического интерфейса;
– наиболее допустимая цена программы;
– условия заказчиков и руководителей по составлению промежуточных результатов реализации проекта;
– единые правила компании по реализации специальных программных средств.
По причине общераспространенности проектов разработки ПО формируется задача обладать знаниями по их управлению. Тем не менее исследования, проведенные за последнее время, были нацелены на описание существующих моделей и определенные случаи их использование. Таким образом, в существующих системах управления проектами остаются неизученными вопросы методов управления и жизненного цикла, которые являются основополагающими для эффективного управления проектами разработки ПО. Неизученные методы реализации процессов управления, в частности управления стоимостью и временем, также мешают эффективно планировать, управлять и успешно завершать проекты в заданных условиях ограничения времени и стоимости.
Вследствие этого возникает необходимость решения научной задачи – моделирования процесса управления проектом разработки ПО, посредством описания моделей жизненного цикла и концепции управления, новых моделей оценки времени и стоимости, новой системы управления.
На первых стадиях управления проектом разработки программного обеспечения необходимо описать цели и рамки проекта, а также взаимосвязь данного проекта с другими, если такие существуют. Указываются запросы заказчика, на удовлетворение которых направлен проект, а также описание целей проекта, программного продукта, который должен быть разработан, чтобы достичь целей проекта. Также указывается, каким образом данный проект будет интегрироваться с другими проектами или процессами [7]. На этом этапе указывается выбранная модель жизненного цикла проекта, перечисляются все важные фазы проекта, их взаимосвязи, зависимости и последовательность выполнения. Проекты по разработке программного обеспечения обычно используют 2 модели: водопадная и инкрементная модели.
Водопадная модель используется для проектов с хорошо определенными требованиями заказчика. Вся функциональность, которую необходимо реализовать на проекте, определяется в начале проекта на фазе Разработки требований. Выходные данные из этой стадии являются входными для других стадий [3]. Проект имеет следующую последовательность фаз, представленных на рис. 2.
Фаза «Разработка требований» включает сбор требований заказчика и их формализацию. Требования – основа для всего проекта.
На фазе «Проектирование» проектная команда разрабатывает документы дизайнов в соответствии с требованиями.
На фазе «Разработка» проектная команда производит продукт в соответствии с документами дизайнов.
На фазе «Верификация» продукт проходит верификацию и приёмку, для того чтобы убедиться, что требования реализованы корректно и продукт удовлетворяет требованиям заказчика.
После стадии «Верификация» проект переходит в фазу «Ввод в эксплуатацию». На данной фазе продукт должен быть развернут для эксплуатации и быть принят заказчиком [8].
Инкрементная модель используется для проектов с недостаточными требованиями заказчика – требования определяются итеративно в течение всего процесса разработки продукта. Проект имеет следующую последовательность фаз, представленных на рис. 3.
Инкрементальная модель применима на проектах с плохо определёнными или не до конца определенными требованиями. Разработка производится итерациями (2–4-недельными циклами). Требования на итерацию оговариваются с заказчиком до старта итерации. Итерация планируется в соответствии с объёмом требований на итерацию, и каждая итерация включает проектирование, разработку и верификацию. Результаты первой итерации используются для уточнения требований на следующую итерацию. Итерации продолжаются, пока не достигнуты цели проекта, определенные в документе требований. Последняя версия построения продукта проходит полную проверку перед вводом в эксплуатацию [4].
Рис. 2. Последовательность фаз в водопадной модели
Рис. 3. Последовательность фаз в инкрементной модели
Очевидно, что создаваемые программные продукты принадлежат к различным классам, обобщить опыт их создания предполагается внутри класса или в рамках отдельных групп. Разграничение на классы и группы, в рамках которых предполагается обобщение, допустит более точно совершить моделирование на ранних этапах реализации новых проектов, аналогичных предыдущим.
В качестве наиболее надежного и совершенного на практике аппарата аналогового моделирования предлагается применить теорию подобия [1].
Концепция теории подобия основывается на том, что в пределах класса явлений или процессов выделяются группы, в которых предполагается обобщение данных единичного опыта.
Под понятием единичный опыт, при разработке программных продуктов, предполагается:
– создание одной (первой) версии программного продукта группой разработчиков;
– создание аналогичной системы другой группой разработчиков;
– создание показательного прототипа системы.
Универсализация опыта разработки программного продукта допускает произвести оценку трудозатрат, стоимости и времени выполнения аналогичного проекта (реализовать подобный программный продукт).
Для использования аналогового моделирования программных проектов требуется установить:
– процессы, которые будут входить в класс;
– процессы, которые будут входить в группы (определить множество условий, определяющее подобие процессов реализации программных проектов) [1].
Параметры проекта и продукта определяют класс реализации проекта, соответственно:
– методом разработки (быстрая разработка, разработка по водопадной, спиральной, инкрементной, открытой и т.д. модели);
– типом разрабатываемого продукта (система обработки транзакций, система поддержки принятия решений, среда разработки, офисное приложение, учетное приложение и т.д.) [2].
Организация групп подобных программных проектов внутри класса определяется условиями подобия.
Процессы реализации программных проектов при детальном сравнении с физическими процессами и явлениями имеют следующие сходные признаки:
– необходимый временной характер (программный продукт и физическое явление происходят во времени, причем внутри конечного, определенного промежут-ка времени);
– наличие логики, определяющей связанность параметров процессов друг с другом и со временем (физические явления имитируются посредством соотношения физических параметров, в программных проектах имитируется соотношение параметров друг с другом, например, от размера продукта и времени на его разработку продукта);
– вероятность установления системы в завершающей стадии, в которой процесс реализуется не на знании ее предыстории, а на знании исходного состояния (для физических процессов – универсальные соотношения выражаются в общем виде в дифференциальной форме; для программных проектов, как правило, предыстория системы отсутствует) [1].
По приведенным выше сходным характеристикам можно сделать вывод о том, что теория подобия исследует один класс систем (класс временных, статических и функциональных систем. Системы с физическими явлениями и системы, в которых реализуются программные проекты, подходят под понятие этого класса, поскольку:
– существует функциональная зависимость между входными и выходными данными системы;
– входные и выходные данные системы установлены на одном и том же множестве моментов времени;
– выходные объекты системы зависят только от состояния, в котором системы получают развитие.
Вследствие этого можно сделать вывод о том, что сходность систем со стороны теории подобия устанавливает общность условий подобия, которые теория возлагает на процессы в исследуемых системах. Соответственно, как для систем с физическими явлениями, так и для программных проектов возможно применений условия подобия.
В ходе исследования было определено, что для повышения эффективности управления проектами разработки программного обеспечения требуется изучить жизненный цикл программных проектов, которая формирует перечень и порядок действий для реализации в проекте, устанавливает позицию процессов управления в жизненном цикле, обосновать регулируемость проекта и возможность его успешного завершения наличием условий устойчивости системы управления, которые допустят принять решение об успешном завершении проекта еще до начала его выполнения. Сформулировано применение теории подобия, как математический аппарат изучения процессов реализации программных проектов по принципу аналогии. В дальнейшем необходимо разработать новые модели оценки времени и стоимости и реализовать эти модели в новой разработанной системе управления программными проектами. Таким образом, в рамках данного исследования будет разработана система, которая должна выполнять следующие функции:
– хранение общей информации о проекте: цели, задачи, заказчик, ключевые сроки;
– формирование календарного плана этапов проекта с указанием сроков начала и окончания каждого этапа, критериев приемки каждого этапа и ответственных;
– распределение ролей в проекте между сотрудниками фирмы-разработчика;
– формирование плана взаимодействия исполнителей и заказчиков в рамках IT-проекта;
– хранение данных о процедурах эскалации и приемки проекта;
– формирование планов оценки проекта, мониторинга и контроля, управления рисками;
– формирование технических планов проекта;
– формирование планов по поддержке программного продукта;
– контроль сроков выполнения задач;
– обеспечение возможности корректировки сроков и исполнителей по различным этапам проекта в случае незапланированной ситуации;
– формирование итогового плана управления проектом.
Библиографическая ссылка
Кочеткова Л.И., Сенкевич Л.Б. СТРУКТУРА ПЛАНА УПРАВЛЕНИЯ ПРОЕКТОМ В ОБЛАСТИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ // Современные наукоемкие технологии. – 2017. – № 6. – С. 62-66;URL: https://top-technologies.ru/ru/article/view?id=36699 (дата обращения: 20.04.2024).