Сфера информационных технологий (IT) в настоящее время – одна из наиболее динамично развивающихся областей человеческой деятельности. Образовательный процесс по специальностям данного направления должен быть максимально гибким, динамично изменяющимся в соответствии с тенденциями развития IT.
В процессе подготовки IT-специалиста жизненному циклу программного обеспечения уделяется особое внимание [3]. Сфера управления проектом разработки программного обеспечения является специфической в силу следующих особенностей:
– программный продукт не является материальным объектом, увидеть и оценить степень готовности, а также оперативно повлиять на процесс разработки крайне сложно;
– описанные в действующих стандартах стадии разработки ПО являются достаточно общими, не ориентированными на специфику конкретного продукта, следовательно, необходимо адаптировать план разработки к конкретному проекту;
– процесс разработки ПО – процесс, который сложно оценивать как в денежном, так и во временном плане.
Управление проектом – это руководство работами команды исполнителей проекта для реализации проекта с использованием общих методов, планирования и контроля работ (видение будущего продукта, стартовые операции, планирование итераций, мониторинг и отчетность), планирование и управление рисками, эффективной организацией работы команды и коммуникационными потоками в команде исполнителей.
Появление программ управления проектами способствовало преобразованию управления проектами в науку, в которой имеются четкие стандарты, методы и технологии. Так, стандарт, разработанный Институтом управления проектами (Project Management Institute) принят в качестве национального стандарта в США (стандарт ANSI), появился и стандарт по качеству в управлении проектами ISO 10006. Применение этих технологий способствует своевременной реализации проектов в рамках выделенных бюджетов и с требуемым качеством. Конечно, программы управления проектами – это только инструмент менеджера проекта, а управление проектом не сводится к компьютерному моделированию.
Программы управления проектами можно использовать по-разному. Для одних это инструмент для компьютерного моделирования проектов и просчета последствий принимаемых решений до их реализации, для других – средство отображения директивных показателей проекта и подготовки отчетности.
Из пакетов, не представленных на нашем рынке, заслуживают упоминания Scitor Project Scheduler – пакет непрофессионального сегмента рынка, который является основным соперником MS Project на западном рынке, а также Artemis Project View – наиболее мощный из западных профессиональных пакетов управления проектами. Artemis Project View работает с базой данных Oracle, довольно дорог и при этом достаточно неэффективен. Его дополнительные возможности невелики, а стоимость в несколько раз выше стоимости других профессиональных пакетов. Потому популярность пакета не высока и на Западе.
В существующих стандартах приведены 9 процессов (областей знаний) по управлению проектами, каждый из которых состоит из определенного набора работ, и пять этапов (фаз) жизненного цикла проекта: инициация, планирование, исполнение, мониторинг и управление, завершение [3]. При этом процессы взаимосвязаны, а этапы проекта могут накладываться во времени друг на друга.
На этапе инициации проекта необходимо выбрать и обосновать вид (тип) программного продукта, который компания собирается разрабатывать, и определить рыночную нишу его распространения, разработать и утвердить концепцию проекта. Недостаточное внимание этого этапа проекта неизбежно приводит к существенным проблемам при планировании, реализации и завершении проекта.
Планирование программного проекта относится к работам, предпринимаемым для подготовки к успешному ведению программно-инженерной деятельности реализации программного продукта и представляет собой: процессы структурного планирования проекта, распределения и назначения ресурсов (материальных и людских) с учетом стоимости и времени выполнения проекта в целом и его отдельных работ.
Как правило, редкий проект выполняется в соответствии с первоначальными планами, поэтому важным элементом системы управления проектом является периодический мониторинг его состояния, анализ причин расхождения с планом и разработка корректирующих воздействий. В качестве одного из возможных подходов внутреннего аудита состояния проекта руководителям программных проектов рекомендуется периодически отвечать на определенные вопросы и анализировать полученные результаты.
Каждый вопрос предлагается оценить по следующей схеме: оценка 0 проставляется, если руководитель даже не знает об этом; 1 – знает, но пока не реагирует на это; 2 – знает, но реагирует периодически; 3 – реагирует постоянно. В зависимости от численности команды, при расчете итогового балла предлагается учитывать следующие поправочные коэффициенты: для малых проектов (до 5 человек) – 1,5; для средних (от 5 до 20 человек) – 1,25. Результаты самооценки: если итоговый балл меньше 40 – завершение проекта сомнительно, 40–59 – в ходе реализации проекта следует ожидать серьезные проблемы, 60–79 – проект, скорее всего, будет успешным, 80–89 – вероятность успеха высока, больше 90–100 % шансов на успех.
Завершение проекта относится к фиксированию результатов программного проекта после передачи полученного программного продукта в эксплуатацию. На этом этапе проводятся приемо-сдаточные испытания (ПСИ) продукта на предмет соответствия его свойств определенным ранее требованиям. Критерии приемки должны определять числовые значения характеристик системы, которые должны быть продемонстрированы по результатам приемо-сдаточных испытаний или опытной эксплуатации и однозначно свидетельствовать о достижении целей проекта. Для проведения процедуры приемки-сдачи создаются специальные документы – программа и методика испытаний программного продукта [5]. Завершение наступает, когда достигнуты цели проекта, или осознано, что цели проекта не будут или не могут быть достигнуты; или исчезла необходимость в проекте, и он прекращается.
Для создания компьютерной модели проекта необходимо проделать следующие шаги:
– укрупненно описать проект – создать Иерархическую структуру работ;
– задать, какие составляющие стоимости будут использованы для финансового анализа и управления проектом;
– составить перечень операций (работ, задач) проекта и задать их характеристики;
– составить перечень ресурсов проекта и задать их характеристики;
– задать взаимосвязи (ограничения на порядок исполнения) операций проекта;
– назначить ресурсы на исполнение операций проекта;
– назначить стоимости на операции, ресурсы и назначения проекта;
– задать ограничения на финансирование, поставки, сроки исполнения операций;
– составить расписание исполнения работ проекта с учетом всех ограничений;
– оптимизировать состав используемых ресурсов;
определить бюджет и распределение во времени плановых затрат проекта;
– определить и промоделировать риски и неопределенности;
– определить необходимые резервы на сроки, стоимости и потребности в материалах для исполнения запланированных показателей с заданной надежностью;
– если заданы директивные сроки, стоимости, ограничения по поставкам, то определить вероятность их успешного соблюдения;
– представить плановую информацию руководству и исполнителям.
В процессе исполнения необходимо:
– вести учет;
– анализировать отклонения исполнения от запланированного;
– прогнозировать будущие параметры проекта;
– моделировать управленческие воздействия;
– вести архивы проекта.
Создание компьютерной модели проекта всегда начинается с разработки Иерархической Структуры Работ (Work Breakdown Structure). Наиболее распространенный подход к структуризации – разбиение проекта на подпроекты, фазы, и т.д. исходя из объектов проекта. Подразделив проект на объекты с максимальной разумной детализацией следует описать процессы, связанные с реализацией каждого объекта.
Наиболее распространенный подход к структуризации – разбиение проекта на подпроекты, фазы, и т.д. исходя из объектов проекта. Так, чтобы произвести велосипед вы должны сделать раму, колеса, тормозную систему и т.д. Подразделив проект на объекты с максимальной разумной детализацией, вы должны описать процессы, связанные с реализацией каждого объекта. Однако возможны и другие подходы к созданию Иерархической структуры работ. Так, например, можно начать с процессов, а затем описывать, к каким объектам эти процессы следует приложить в данном проекте. Еще одна полезная структура – структура ответственности, в которой операции проекта соотносятся лицам, отвечающим за их исполнение.
Иерархические структуры работ позволяют получать отчетность по любым своим элементам. Таким образом, структура объектов позволяет подводить «Итого» по объектам проекта, структура процессов – по процессам проекта, а структура ответственности – контролировать, как участники проекта справляются с работами в своих зонах ответственности.
Одну Иерархическую структуру работ можно завести в любом пакете управления проектами. Как уже упоминалось, без иерархии работ не удастся полностью описать операции проекта и без этой функции компьютерное моделирование проектов просто теряет смысл.
Характеристики операций проекта определяют и те показатели, который в дальнейшем используются для моделирования проекта. Перечислим основные исходные параметры, которые можно задать и использовать при моделировании исполнения операций проекта [3]:
– длительность исполнения;
– объем работ на операции;
– трудоемкость операции (ресурсо-часы, необходимые для ее исполнения);
– календарь операции;
– прямые затраты на операцию;
– тип операции (что является исходной информацией – длительность, трудоемкость, или объем работ, или операция исполняется неопределенное время – от одного события до другого, или операция является вехой или контрольным событием, то есть имеет нулевую длительность и определяет важные события проекта, например завершение исполнения фаз);
– ограничения на сроки исполнения операции (например, начало не раньше определенной даты).
Календарь операции определяет промежутки времени, когда операцию можно исполнять. Так, например, некоторые операции можно исполнять только в дневное время, другие – только летом и т.п. Календарь операции используется как ограничение при составлении расписания исполнения работ проекта. Задать календарь операции можно во всех пакетах, но используются они при составлении расписания по-разному. В большинстве пакетов время исполнения работы определяется или календарем операции, или календарем назначенных ресурсов.
Для составления расписания исполнения проекта без учета ограниченности ресурсов используется широко известный метод критического пути, позволяющий получить оптимальное решение задачи. Поэтому расписания, составленные разными пакетами при тех же исходных данных, не будут отличаться. В процессе составления расписания определяются ранние и поздние даты (старт и финиш) исполнения операций проекта. Операция не может быть начата ранее даты раннего старта, а опоздание исполнения операции по отношению к поздним датам означает задержку проекта в целом. Промежуток времени между ранним и поздним стартом операции называется полным резервом, а операции, у которых полный резерв равен нулю, называются критическими. Совокупность критических операций образует критический путь.
Критический путь без учета ограниченности ресурсов вычисляется всеми пакетами управления проектами.
Кроме расписания от начальной даты, пакеты управления проектами вычисляют и расписание назад от заданной пользователем директивной даты завершения проекта. Это расписание позволяет определить, когда следует начать исполнение работ проекта, чтобы завершить его к назначенной дате.
Использование программ управления проектами в процессе подготовки программистов позволит студентам изучить особенности разработки ПО «изнутри», понять, каким образом происходит планирование и контроль процесса реализации программы.
Рецензенты:
Долгоносов В.Н., д.т.н., доцент кафедры «МДиГ» Карагандинского государственного технического университета, г. Караганда;
Базаров Б.А., д.т.н., профессор, зав. кафедрой «СиТ» Карагандинского государственного индустриального университета, г. Темиртау.
Библиографическая ссылка
Яворский В.В., Сергеева А.О. КОМПЬЮТЕРНАЯ МОДЕЛЬ ПРОЕКТА КАК ОСНОВА ИЗУЧЕНИЯ ПРОЦЕССА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ // Фундаментальные исследования. – 2015. – № 2-20. – С. 4418-4421;URL: https://fundamental-research.ru/ru/article/view?id=38085 (дата обращения: 19.04.2024).