Способы определения времени выполнения работ проекта

Определение продолжительности работ проекта

Длительность работ проекта может быть определена исходя из оценки их трудоемкости или экспертным методом. В курсовой работе рекомендуется использовать экспертный метод оценивания, при котором экспертно определяются оптимистичная оценка продолжительности работы (t_min) и пессимистическая оценка (t_max).

Ожидаемая продолжительность работы t_ож рассчитывается как математическое ожидание для нормального распределения. В этом случае, ожидаемая продолжительность определяется по формуле:

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

Таблица 1 Расчет длительности работ проекта

Этап	Номер работы	Содержание работы	Трудозатраты, чел. дни
tmin	tmax	tож
Разработка алгоритмов
1.1	Разработка функциональной схемы программного комплекса	7,2	11,2	8,8
1.2	Разработка основных структур данных	1,8
1.3	Разработка алгоритма определения логической несовместимости операторов	3,2
1.4	Разработка алгоритма нахождения взаимно независимых операторов	1,8
1.5	Разработка алгоритма нахождения ранних сроков окончания выполнения операторов	1,8
1.6	Разработка алгоритма нахождения поздних сроков окончания выполнения операторов	13,2
1.7	Разработка алгоритма нахождения необходимого числа процессов	14,4
Разработка программных модулей	19,2
2.1	Разработка программного модуля для определения логической несовместимости операторов	4,6
2.2	Разработка программного модуля для нахождения множества взаимно независимых операторов
2.3	Разработка программного модуля для нахождения ранних сроков окончания выполнения операторов
2.4	Разработка программного модуля для нахождения поздних сроков окончания выполнения операторов	7,5
2.5	Разработка программного модуля нахождения необходимого числа процессов
Тестирование, отладка и исправление недочетов	14,2
3.1	Тестирование и отладка отдельных модулей
3.2	Разработка интерфейса и комплексное тестирование	13,5	10,2
Подготовка к внедрению
4.1	Разработка программной документации (руководства пользователя)
4.2	Опытная эксплуатация

6. ПОСЛЕДОВАТЕЛЬНОСТЬ РАЗРАБОТКИ ПРОЕКТА
В MS PROJECT

Источник

Лекция №10

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

Длительность проекта – это временная характеристика, являющаяся одним из трех главных взаимосвязанных компонентов менеджмента любого проекта: «стоимость-время-качество».

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

1. построить план управления временными рисками проекта,

2. уточнить стоимость и трудоемкость проекта,

3. сформировать график работ,

уточнить объемы требуемых ресурсов.

Рис. Парадигма количественного оценивания проекта

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

К факторам затрудняющим достижение целей проекта относятся:

· Отсутствие адекватного оборудования, программного обеспечения;

· Отсутствие квалифицированного персонала;

· Замедление цикла утверждения;

· Плохая координация с другими компаниями;

· Недостаточная компетенция менеджеров проекта.

Количественные показатели «стоимость,C», «трудоемкость,Т» и «длительность,Д» являются взаимосвязанными величинами и характеризуют проект с количественной стороны.

Где С_рс – средняя заработная плата персонала проекта в месяц;

где N –численность команды проекта.

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

При определении трудоемкости проекта ИС учитывают:

· Структура пооперационного перечня задач (WBS):

Ø Задачи по сравлению технического задания;

Ø Задачи по разработке программного и технологического обеспечения (архитектура, код, тестирование);

Ø Задачи по внедрению ИС;

Ø Задачи, требующие дополнительных затрат (менеджмента и документирования);

· Дополнительные затраты на переговоры, договоры купли-продажи, консалтинг;

· Хронологические данные по трудоемкости и производительности;

· Среда разработки (операционная система для целевой ИС, языки программирования, использование инструментов ( CASE -средств) проектирования);

· Уровень профессионального опыта и др.

В общем виде длительность проекта можно представить как сумму продолжительности работ по составлению технического задания Д_ТЗ, собственно разработки Д_раз и внедрения Д_вн.

Источник

Как правильно оценивать сроки проекта на примере веб-студии

В чем сложность

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

• Разработка программ — это процесс интеллектуальной деятельности. Есть типовые задачи, которые уже делались раньше, оценить такие не составляет труда. Но есть и нестандартные задачи. У нас таких обычно 20-30% работ по проекту. Эти задачи невозможно оценить, потому что неизвестно сколько они займут времени и какие могут возникнуть проблемы при их разработке. Простой пример: попробуйте ответить на вопрос: «Сколько времени займет путь из Москвы до поселка Заполицы на автобусе? И сколько стоит такая поездка?». Вряд ли вы вообще были там раньше, поэтому для вас эта задача нестандартная, сходу и не скажешь сколько. С примером просто — позвонил на автовокзал, узнал цену и продолжительность поездки. Но даже здесь есть риск застрять в пробке. А заказчик будет звонить вам и трясти результат. И правильно сделает: пообещали — выполняйте.
• Требования заказчика. Практически в любом проекте в ходе реализации меняют первоначальные требования. Заказчик мог что-то забыть или появились новые хотелки уже после старта проекта.
• Еще одна проблема, вытекающая из того, что деятельность интеллектуальная — это квалификация разработчика. Профессионал может выполнить задачу в разы быстрее новичка.

Эти три причины я написал в порядке убывания их проблемности.

Как мы их устраняем

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

Следующие две проблемы посерьезнее. Начну со второй — меняющиеся требования заказчика.
Мы пользуемся двумя вариантами построения процессов разработки: Scrum и НЕScrum.

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

Но все в ТЗ описать невозможно, поэтому в ходе проекта всегда образуются спорные вопросы. Например, это происходит там, где заказчик ожидал чего-то де-факто, а для нас это трудная (или долгая) задача и на нее требуется время. Портить отношения с заказчиком не хочется, поэтому приходится либо тратить время менеджера на обсуждение этой проблемы, либо тратить время программиста для решения задачи, либо тратить время менеджера + время программиста для придумывания альтернативной задачи и ее решения. В этом случае мы обычно выбираем вариант, который принесет наибольшую пользу бизнесу заказчика (ведь «хотелки» часто не имеют под собой серьезного обоснования, и, порой, даже вредят).

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

Как делается в скраме?

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

Работа с заказчиком организована в трелло.

А работа команды организованна в youtrack’е.

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

Последняя проблема — оценка длительности нестандартных задач. К слову, стандартные задачи оцениваем по этой же методике. То, что я буду описывать — это часть скарама, оценка методом покер-планирования. Задачи по очереди берутся из Backlog’а. Оценку проводит вся проектная команда, члены которой, (внимание!) должны прийти к единому решению. Если хотя бы один из них не согласен, то обсуждение задачи будет продолжено. Оценивают в условных единицах, мы их называем story points (s.p.). Эти условные единицы представляют из себя часть последовательности Фибоначчи: 0,1,2,3,5,8,13,21. Задачи, оценка которых выше 21, обязательно разбиваются, чтобы избежать грубой оценки.

Сам процесс оценки проходит так: первым говорит тот, кто непосредственно реализует данную задачу: делали мы такое или нет, как это будет программироваться, где могут возникнуть проблемы, с какой вероятностью они возникнут — все, что может помочь при оценке сложности задачи. Затем высказываются остальные, задаются вопросы. У каждого есть 8 карт с числами Фибоначчи 0,1,2,3,5,8,13,21 (используется специальная колода карт). Когда все готовы голосовать, каждый выкладывает одну карту рубашкой вверх. Когда все карты выложены, они переворачиваются, и все видят оценки.

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

В итоге мы имеем гибкую команду, способную подстраиваться под меняющиеся требования заказчика и умеющую точно прогнозировать сроки по проектам.

Источник

Определяем время, необходимое для выполнения проекта

Перевод статьи «How to estimate time for a project/task accurately».

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

Люди пытаются перестраховаться и закладывают дополнительные 500% времени «просто на всякий случай» – и этого все равно оказывается недостаточно. Менеджеры, в свою очередь, стараются сжать «заведомо раздутые сроки», чтобы иметь возможность пообещать клиенту что-то более приемлемое (это обычная менеджерская болезнь). У разработчиков есть своя «болячка» – тенденция бормотать что-то невнятное вместо озвучивания конкретных цифр.

Сам я (и уверен, вы тоже) ненавижу вопросы вроде «Когда будет готово?», но без них не обойтись в любом проекте, который кем-то контролируется.

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

Шаг 1. Выяснение требований клиента

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

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

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

Шаг 2. Расположите эти действия по порядку

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

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

Шаг 3. Управление рисками

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

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

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

Шаг 4. Делаем прикидки

Есть несколько методов оценки времени.

Экспертное мнение

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

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

Трехточечная оценка

Это один из самых распространенных и простых методов. В рамках этого подхода определяется оптимистическая (O = Optimistic), пессимистическая (P = Pessimistic) и реалистическая / средняя (M = Middle) оценки.

Значения P, M и O определяются экспертами и выражаются в часах, днях, денежных единицах. Это может делаться в ходе обсуждений внутри команды, занимающейся проектом. Для этого задаются вопросы вроде «Сколько времени это займет при условии, что все будет идти по плану, без всяких рисков и проблем?», «Каким может быть самый плохой сценарий и сколько в таком случае потребуется времени/усилий?» и т. п. Затем полученные значения P, M и O закладываются в формулу (O + 4 M + P) / 6.

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

Стоимость качества

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

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

• Стоимость действий по предотвращению дефектов.
• Стоимость тестирования.
• Коррекция внутренних ошибок.
• Исправление проблем с интеграцией.
• Стоимость установки и конфигурации программы в условиях реального окружения и данных.

Аналоговая оценка

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

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

Параметрическая модель

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

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

Оценка снизу вверх

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

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

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

Заключение

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

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

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

Когда человек не хочет или не имеет времени на выяснение требований или декомпозицию проекта, вы можете услышать о различных вариантах умножения предположительной оценки на число пи (3,14) или е (2,71). Это не маленькие множители, их применение может сильно влиять на оценку. Но все это – проблема отсутствия внимания к мелочам или лени разбираться во всем вышеизложенном.

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

Источник