Диплом (1220284), страница 8

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 8)

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

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

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

Успешность проекта различным образом оценивается в разных методиках. Успешность может разным образом оцениваться участниками проекта.

Группы оценок успешности.

• Ориентированные на контракт, например традиционные методологии, в том числе PMBOK: «проект успешен, если выполнен согласно утвержденным критериям: объему, сроку, качеству». То есть проект успешен, если исполнен и закрыт договор между Заказчиком и Исполнителем (вне зависимости от того, являлся ли он юридическим документом в случае внешних проектов или определялся как-то иначе в случае внутренних проектов). При этом оценка успешности единая как для заказчика так и для исполнителя.

• Ориентированные на заказчика, например гибкие методологии SCRUM, частично управление программами, направленное на длительное взаимодействие, а не на один проект/контракт: «проект успешен, если заказчик удовлетворен». Здесь делается акцент на продолжение сотрудничества Исполнителя с Заказчиком в рамках последующих проектов и иного взаимодействия, либо проект можно рассматривать как программу из нескольких небольших проектов. Оценка успешности рассматривается в основном с точки зрения заказчика.

• Сбалансированные, например PRINCE2: «проект успешен при сбалансированности по крайней мере по трем категориям — бизнеса, ориентации на пользователя и технологической зрелости». Здесь делается акцент на финансовой успешности проекта, удовлетворенности пользователей и развитии (косвенная польза для самого исполнителя). Оценка успешности может различаться с точки зрения бизнеса, пользователя и исполнителя. Такие методики оценки чаще используются для внутренних проектов.

Так, например, проект, уложившийся в согласованные сроки и затраты, но не окупившийся по результатам проекта (затраты велики, результат неактуален к окончанию проекта, заказчик не может воспользоваться результатом и т.п.) будет успешен по традиционной методологии, но не успешен по методологии, ориентированной на заказчика. Ответственность за не успешность такого проекта несет заказчик и, в некоторых случаях, проектный офис либо служба заказчика. В целом можно определить цель управления проектами следующим образом: «Целью управления проектом является достижение заранее определенных целей при заранее известных ограничениях и целесообразном использовании возможностей, реагировании на риски.» Даже при достижении поставленных целей и целесообразности изменений, проект может не соответствовать ожиданиям заинтересованных сторон. В проектах с высоким уровнем изменений требуется управление ожиданиями.

1. Процедуры управления проектом

Процедуры управления проектом по традиционной методологии.

Последовательность процедур управления проектом:

• определение среды проекта;

• формулирование проекта;

• планирование проекта;

• техническое выполнение проекта (за исключением планирования и контроля);

• контроль над выполнением проекта.

Процедуры управления проектом по методологии PMI.

Основные процедуры и процессы PMI описаны в стандарте PMBOK:

• определение требований к проекту;

• постановка четких и достижимых целей;

• балансирование конкурирующих требований по качеству, возможностям, времени и стоимости;

• адаптация спецификаций, планов и подходов для нужд и проблем различных заинтересованных лиц (стейкхолдеров).

Процедуры управления проектом по методологии IPMA

Системное представление Управления проектами IPMA.

Процедуры управления проектом по методологии PRINCE2:

• начало проекта;

• запуск проекта;

• планирование проекта;

• управление проектом;

• контроль стадий;

• контроль границ стадий;

• управление производством продукта;

• завершение проекта.

Прочие процедуры (управление командой, контрактами) вынесены «за рамки» методологии и называются инструментарием менеджера проекта. Кроме того, методология рассматривает «компоненты», которые состоят из Бизнес плана (Business Cаse), организации, планирования, управления рисками, управления качеством, управление конфигурацией, контроля и управления изменениями.

1. План управления проектом

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

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

Существует множество методов для оценки программного обеспечения, среди которых можно выделить общие алгоритмы оценки затрат на разработку программного обеспечения. Для данного программного продукта будет применен COnstructive COst MOdel (COCOMO – модель издержек разработки). Это алгоритмическая модель оценки стоимости разработки программного обеспечения, разработанная Барри Боэмом (Bаrry Boehm). Модель использует простую формулу регрессии с параметрами, определенными из данных, собранных по ряду проектов.

Имеется три типа данной модели :

• базовый уровень;

• средний уровень;

• детальный уровень.

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

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

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

1. Расчет затрат на разработку автоматизированной информационной системы

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

Себестоимость программы рассчитывается по формуле (5.1) :

(5.1)

,

где – себестоимость программы, руб.;
– зарплата, руб.;

– эксплуатационные расходы, связанные с разработкой и внедрением программы, руб. [19].

1. Выбор специалистов

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

• опыт работы от 1 года до 3 лет;

• английский язык - на уровне чтения технической документации;

• опыт программирования на С/С++, Python (Mаtplotlib);

• опыт многопоточного программирования;

• linux на уровне опытного пользователя;

• аналитический склад ума.

Чтобы определить среднюю заработную плату, необходимо определить ранг программиста обладающий данными навыками. Есть 3 ранга.

• Junior — к данным программистам относятся студенты старших курсов и без опыта работы. Не способен выполнить задачу полностью без помощи наставника. Знание одного языка программирования на базовом уровне. Предметную область знает плохо. Английский Базовый — Чтение технической литературы.

• Middle — программист 1-3 года опыта. Способен работать в одиночку и в команде. Может планировать разработку на 1-2 недели в перед. Знание одного языка программирования на продвинутом уровне и 2 языка на базовом уровне. Английский на уровне чтение документации и ведения обсуждения.

• Senior - программист с опытом работы от 3 лет и более. Может руководить командой от 2 и более разработчиков. Планирует свою работу и работу команды на весь проект. Специализируется на нескольких языках программирования, во всех специализируется как разработчик высокого класса(использования в коммерческой разработке от 2 лет), может выступать в качестве эксперта в сложных момента в проекте. Свободное пользование английским.

Чтобы определить размер заработной платы для каждого из рангов обратимся к сервисам поиска таким как HH.ru [20] и ITmozg.ru [21] для Хабаровска. Размеры заработной платы представлены в таблице 4.

Таблица 4 - Размер заработной платы

По данным критериям и уровню заработной платы выбирается программист для проекта уровня С++/Python Middle со средней заработной платой в 35 тысяч рублей.

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

• знание английского на уровне чтения документации;

• администрирование Unix-систем;

• знание bash и Python.

Чтобы определить размер заработной платы для специалиста с данными навыками обратимся к HH.ru [20] и ITmozg.ru [21] для Хабаровска. В среднем размер заработной платы равен 25000 рублей.

Таблица 5 - Исходные данные для расчета себестоимости и цены программного обеспечения

1. Расчет трудоёмкости создания программного продукта

Для расчета рекомендуемой зарплаты разработчика программного обеспечения необходимо определить трудоёмкость создания программного продукта, которая рассчитывается по формуле (5.2):

Характеристики

Список файлов ВКР