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

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

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

инициация.

планирование.

исполнение.

анализ.

оперативное

управление.

завершение.

Процесс управления проектом ИС осуществляется в соответствии с методологией Waterfall (от анг. «водопад»). Расскажу о ней подробно.

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

Чтобы двигаться по водопаду, нужно иметь четкое техническое задание и понимание шагов, следующих друг за другом. Данную модель я выполняла в МS Visio.

Недостатки методологии Waterfall.

Сейчас Waterfall всё ещё популярен, но для того же IT подходит всё меньше по ряду причин:

Очень много документов, которые нужно постоянно актуализировать.

Подробнейший план может создать не только иллюзию безопасности, но и ложные впечатления о работе над проектом. За фразами «60% проекта выполнено» может не быть никакого полезного результата. Это всего лишь манипуляция.

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

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

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

Преимущества методологии Waterfall

В IT всё больше команд переходит на гибкие методологии по двум причинам: команды разработчиков небольшие, а дедлайны можно легко подвинуть. Но для крупных проектов каскадная методология всё ещё актуальна, потому что:

Устойчива к обновлению кадров. Благодаря очень подробному документированию каждого этапа, участники могут приходить и уходить, но на сроки работы это никак не повлияет.

Дисциплинирует, благодаря плану и чёткой последовательности этапов и строгому менеджменту.

Гибкая на ранних этапах. До этапа разработки можно вполне легко вносить изменения в предыдущие этапы.

Прозрачна. Заранее понятно, на каком этапе, что будет происходить, поэтому становится проще прогнозировать бюджеты и набирать команду. 4

В данном проекте в процессе разработки и эксплуатации ИС «ССФУ» участвуют студенты 3 курса направления «Бизнес-информатика», которые заинтересованы в успешной реализации проекта. В этом процессе между ними распределяются роли, каждый из которых выполняет определенный набор функций. При этом участником проекта может быть любое физическое лицо (зарегистрированный пользователь системы).

Участники проекта – это субъекты управления, взаимодействующие между собой и объектом управления при принятии управленческих решений в процессе его осуществления.
Каждый участник проекта ИС «ССФУ» выполняет роль, в соответствии со своими требованиями.

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

Также необходимо посторить календарный план.

Календарный план – это проектный документ, который позволяет определить оптимальный порядок выполнения работ, установить сроки завершения каждого из его этапов.

Для создания календарного плана проекта ИС «ССФУ» я использовала MS Project. Затем собрала необходимые данные у участников проекта ИС и внесла их в календарный план.

Календарный план данного проекта состоит из 3 основных частей:

1.На первом этапе необходим сбор функциональных требований проекта ИС. Он выполняет несколько задач:

-поиск данных;
-составление анкеты;
-составление вопросов для интервью;
-теоретическое изучение основ разработки требований к ИС;
-изучение методов сбора и анализа требований ИС;
-сбор и анализ требований к проекту ИС «ССФУ»;
-использование данных требований при разработки сайта ИС «ССФУ».

2. На втором этапе происходит создание сайта проекта ИС, который, в свою очередь, проходит в несколько этапов:

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

3. Третий этап заключается в завершении работы над сайтом проекта ИС. Для этого необходима обработка данных, которая проходит в 2 этапа:

- создание доклада,
- создание презентации.

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

Я, как организатор проекта ИС «ССФУ», постоянно отслеживала ход реализации проекта. Время выполнения проекта заняло у нас 56 дней. В течение этого времени могут возникнуть изменения.

В ходе реализации проекта ИС «ССФУ» я передавала отчеты о ходе его выполнения заказчику. Это краткие документы, основанные на информации, извлекаемой из подробных отчетов о проекте. В этих отчетах должна быть та информация, которая позволяет четко оценить степень готовности создаваемого сайта.

Для определения более точного контроля я составила график контроля выполняемых работ проекта ИС «ССФУ».

В ходе реализации проекта ИС «ССФУ» могут возникнуть риски, при котором грамотное управление может спасти проект, а неверные действия могут принести ущерб. Поэтому мы не боремся с рисками – мы ими управляем.

В ходе всего проекта команда должна уделять внимание дисциплине управления рисками. Основные ее характеристики:

она всеобъемлюща и принимает во внимание все составляющие проекта: людей, бизнес-процессы, технологические элементы и т.д.;

она включает в себя пошаговый, систематический и воспроизводимый процесс управления рисками проекта;

ее использование непрерывно на протяжении всего жизненного цикла проекта;

она превентивна и не исходит из идеологии действия по факту случившегося. 2

Внешние риски находятся в окружении, а внутренние риски — это все потенциальные проблемы организации и проектной команды. Также можно выявить риски, которые могут появиться у участников проекта ИС «ССФУ» и как их преодолеть.

Сбор функциональных требований.

ИТ-инфраструктура

Разработка интерфейса

Управление контентом

Управление качеством

Определение стоимости

Управление длительностью

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

2. В ИТ-инфраструктуре могут быть некорректные настройки и работы алгоритмов, также нарушение целостности данных

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

3.В разработке интерфейса может возникнуть сбой в системе конструктора Wix, удаление или потеря сайта.

Для преодоления риска необходимо создать резервную копию на разных устройствах.

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

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

Для преодоления риска необходимо тщательно изучить критерии оценки и использовать только проверенные программные продукты, например ISO.

6.При определении стоимости проекта возможно несоблюдение требований заказчика.

Для преодоления риска необходимо проводить регулярный анализ требований.

7.При определении длительности проекта риском может быть несоответствие поставленным срокам.

Для преодоления риска необходимо согласовывать сроки с заказчиками.

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

В данном проекте для описания длительности проекта ИС я изучила и построила календарный план. Графически он изображен на диаграмме Ганта.

Все вышеперечисленные работы проводились в программе MS Project, MS Exel и MS Visio.

В заключении следует отметить, что поставленные цели и задачи выполнены.

Список литературы

Грекул, В. И. Методические основы управления ИТ-проектами : учебник / В. И. Грекул, Н. Л. Коровкина, Ю. В. Куприянов. – Москва : Интернет-Университет Информационных Технологий (ИНТУИТ) : Бином. Лаборатория знаний, 2010. – 392 с. : ил., табл., схем. – (Основы информационных технологий). – Режим доступа: по подписке. – URL: https://biblioclub.ru/index.php?page=book&id=233070 (дата обращения: 09.12.2021). – ISBN 978-5-9963-0466-0. – Текст : электронный

Грекул, В. И. Управление внедрением информационных систем : учебник / В. И. Грекул, Г. Н. Денищенко, Н. Л. Коровкина. – Москва : Интернет-Университет Информационных Технологий (ИНТУИТ) : Бином. Лаборатория знаний, 2008. – 224 с. – (Основы информационных технологий). – Режим доступа: по подписке. – URL: https://biblioclub.ru/index.php?page=book&id=233072 (дата обращения: 10.12.2021). – ISBN 978-5-94774-944-1. – Текст : электронный.

Парфенова, В. Е. Управление проектами: учебное пособие для обучающихся по направлению подготовки 38.03.02 Менеджмент : [16+] / В. Е. Парфенова ; Санкт-Петербургский государственный аграрный университет (СПбГАУ). – Санкт-Петербург : Санкт-Петербургский государственный аграрный университет (СПбГАУ), 2021. – 41 с. : табл. – Режим доступа: по подписке. – URL: https://biblioclub.ru/index.php?page=book&id=621138 (дата обращения: 09.12.2021). – Библиогр. в кн. – Текст : электронный.

Автор: Александр Машков. Модель водопада: плюсы, минусы, подводные камни электронный ресурс: журнал «weeek» (дата публикации: 21.05.2021г) - https://weeek.net/ru/blog/chto-takoe-waterfall (дата обращения: 24.11.2021г.)

Автор: В.И. Грекул, Н.Л. Коровкина, Ю.В. Куприянов. Проектирование информационных систем электронный ресурс: «ИНТУИТ» учебный курс -2012г. https://publications.hse.ru/mirror/pubs/share/folder/1j6uku79db/direct/53441014 (дата обращения: 10.11.2021г.)

Автор: Е.Б. Солонин. «Управление проектами при разработке информационных систем проектами электронный ресурс: журнал «Study urfu» (дата публикации: 13.04.2010г.) https://study.urfu.ru/Aid/Publication/9583/1/Solonin.pdf (дата обращения: 10.11.2021г.)

Код для цитирования: Скопировать