Расчет трудоемкости создания проекта
Варианты использования
Основная цель создания любой программной системы - создание такого программного продукта, который помогает пользователю выполнять свои повседневные задачи. Для создания таких программ первым делом определяются требования, которым должна удовлетворять система. Однако если дать пользователям написать эти требования на бумаге, то часто можно получить список функций, по которому трудно судить, будет ли будущая система выполнять свое назначение, и сможет ли она облегчить пользователю выполнение его работы вообще. Непонятно какие из выполняемых функций более важны и для кого.
Для того чтобы более точно понять как должна работать система, все чаще используется описание функциональности системы через варианты использования (Use Case или прецеденты). Варианты использования это - описание последовательности действий, которые может осуществлять система в ответ на внешние воздействия пользователей или других программных систем. Варианты использования отражают функциональность системы с точки зрения получения значимого результата для пользователя, поэтому они точнее позволяют ранжировать функции по значимости получаемого результата.
Варианты использования предназначены в первую очередь для определения функциональных требований к системе и управляют всем процессом разработки. Все основные виды деятельности, такие как анализ, проектирование, тестирование выполняются на основе вариантов использования. Во время анализа и проектирования варианты использования позволяют понять как результаты, которые хочет получить пользователь, влияют на архитектуру системы и как должны себя вести компоненты системы, для того чтобы реализовать нужную для пользователя функциональность.
В процессе тестирования, описанные ранее варианты использования, позволяют проще оценить точность реализации требований пользователей и позволяют провести пошаговую проверку этих требований.
Стратегия использования прецедентов при определении требований определяет необходимость дополнительно к вопросу «что пользователи ждут от системы?» задавать вопрос «что система должна сделать для конкретного пользователя?». Такой подход позволяет искать функции, которые нужны многим пользователям, и исключать те возможности, которые не могут помочь пользователям выполнять свои повседневные задачи.
Диаграмма вариантов использования состоит из актеров, для которых система производит действие и собственно действия Use Case, которое описывает то, что актер хочет получить от системы. Актер обозначается значком человечка, а Use Case - овалом. Дополнительно в диаграммы могут быть добавлены комментарии.
Ответы на следующие вопросы позволят определить актеров, взаимодействующих с системой:
· кто взаимодействует с системой или использует систему;
· кто передает или принимает информацию в/из системы;
· кто является внешним по отношению к системе.
Каждый вариант использования показывает, как конкретный актер использует систему и в дальнейшем расширяется диаграммами состояний и последовательности действий.
Между актерами и вариантами использования могут быть различные виды взаимодействия. Основные виды взаимодействия следующие:
· Простая ассоциация - отражается линией между актером и вариантом использования (без стрелки). Отражает связь актера и варианта использования.
· Направленная ассоциация - то же что и простая ассоциация, но показывает, что вариант использования инициализируется актером. Обозначается стрелкой.
· Наследование - показывает, что потомок наследует атрибуты и поведение своего прямого предка. Может применяться как для актеров, так для вариантов использования.
· Расширение (extend) - показывает, что вариант использования расширяет базовую последовательность действий и вставляет собственную последовательность. При этом в отличие от типа отношений «включение» расширенная последовательность может осуществляться в зависимости от определенных условий.
· Включение - показывает, что вариант использования включается в базовую последовательность и выполняется всегда (на рисунке не показан).
Рассмотрим диаграмму прецедентов для разрабатываемой системы. Разделим ее для каждого актанта системы.
Для начала рассмотрим как соотносятся между собой роли пользователей системы (рис. 2.1).
Рисунок 2.1. – Взаимосвязь пользователей системы
Схема показывает связи обобщения между ролями пользователей системы. Клиент, Продавец и Администратор наследуют функциональность, доступную общей роли «Пользователь», и к тому же имеют большой набор собственных возможностей. Менеджер обладает всеми правами продавца, расширенными общими возможностями. В его правах находятся утверждение документов системы. Администратор, кроме стандартных, выполняет функции настройки, выгрузки и резервирования данных. Рассмотрим диаграммы прецедентов каждого из участников бизнес-процесса.
Любой пользователь имеет право выполнять функции, представленные на рисунке 2.2.
Рисунок 2.2. – Диаграмма прецедентов Пользователя
Как уже было сказано, указанные функции пользователя доступны всем ролям системы.
Ниже приведены схемы прецедентов для ролей, наследующих функциональность Пользователя – Клиента, Администратора, Поставщика, Менеджера, Продавца (рис. 2.3 – 2.6).
Рисунок 2.3. – Диаграмма прецедентов Клиента
Рисунок 2.4. – Диаграмма прецедентов Администратора
Рисунок 2.5. – Диаграмма прецедентов Менеджера
Рисунок 2.6. – Диаграмма прецедентов Продавца
На основе выделенных прецедентов и построенных диаграмм строится дальнейшая работа по проекту, производится его оценка, вносятся коррективы в требования, строятся графики реализации, составляются инструкции пользователей и т.д. Выделение прецедентов является важнейшим этапом аналитической работы и ему уделяется особое внимание.
Каждый прецедент документируется соответствующим образом. Шаблон такого документа обычно принимается организацией-разработчиком самостоятельно, однако существует общий шаблон оформления прецедентов. В документе обязательно описываются начальные условия для выполнения прецедента, исполнители (актеры), основной и альтернативный потоки, условия переключения потоков, результирующие данные и дополнительные условия, так называемые нефункциональные требования, например требования к дизайну и производительности.
Не следует подробно документировать каждый прецедент в отдельности, часто требуется лишь краткое описание действий, происходящих в прецеденте. Приведем описание выделенных прецедентов с указанием сложности их реализации (Табл. 2.1). Сложность указывает непосредственный разработчик. Эта процедура важна для создания плана реализации и оценки проекта.
Таблица 2.3 – Описание прецедентов и их сложность
| Актер | Прецедент | Сложность |
| Общие | Запросить пароль | |
| Пользователь забыл пароль и запрашивает его у системы. На его контактный э-адрес, прописанный в БД системы высылается пароль. | ||
| Пройти аутентификацию | ||
| Процедура аутентификации. Пользователь вводит имя и пароль. | ||
| Администратор | Установить серверную часть | |
| Проверка минимальных требований. Процедура установки требует наличия системных компонентов Microsoft SQL, ASP.NET… При их отсутствии предлагается выбрать директорию установки. Установка требует ввода серийного номера. При ошибках – откат установки. | ||
| Установить клиентскую часть | ||
| Проверка минимальных требований, ввод серийного номера, указание директории установки, XML шлюза. При ошибках – откат установки. | ||
| Управлять пользователями | ||
| При первом запуске серверного приложения администратор создает пользователей, объединяет их в группы. Для Менеджера кроме прочей информации указывается его Территория продаж. Продавец подотчетен Менеджеру. | ||
| Управлять статьями помощи | ||
| Пользователи имеют доступ к помощи по работе с приложением, часто задаваемым вопросам. Администратор должен иметь возможность редактировать эту информацию через удаленное веб-приложение или из БД. | ||
| Экспортировать данные | ||
| Экспорт в Excel или CSV таблиц поставщиков, заказчиков… | ||
| Управлять профилем компании | ||
| При первом запуске администратор создает профиль компании с указанием параметров. Эти значения могут быть изменены в любой момент из клиентского приложения пользователем, у которого на это есть разрешение администратора. | ||
| Продавец | Просмотреть список запросов Управлять запросами | |
| Продавец может создавать запрос вручную, изменять статус запросов, редактировать запросы. | ||
| Управлять предложениями | ||
| Продавец рассматривает Требование и составляет Предложение. При этом он имеет доступ к информации об имеющихся у вендоров товарах. Предложение может подтверждаться Менеджером, а затем отправляется Клиенту. | ||
| Управлять списком заказов на покупку | ||
| Клиент отвечает на Подтверждение предложения подтверждением номера Предложения и сроком оплаты, если возможно. Осуществляется поиск Предложения. Для найденного Предложения возможно создать Заказ на покупку. Заказ на покупку утверждается Менеджером. | ||
| Управлять списком заказов на поставку | ||
| Для утвержденного Заказа на покупку можно сгенерировать Заказ на поставку. Заказ на поставку также можно создать вручную для пополнения склада. Заказы на поставку могут создаваться из Предложений поставщиков. В любом случае перед посылкой Заказа на поставку он утверждается Менеджером | ||
| Просмотреть список товаров на складе Просмотреть информацию о товаре Просмотреть список клиентов | ||
| Пользователь должен иметь возможность отправить уведомление о том, что запрошенные товары имеются в наличии. Для этого пользователь должен знать, кто заказывал товар. Выбрав товар, пользователь может просмотреть незаконченные заказы по ним. Пользователь должен иметь возможность просмотреть данные о товаре, открыв PDF документ | ||
| Создать акт возврата | ||
| Пользователь проверяет номер возвращенного товара, содержимое возвращенного пакета, причину возврата. Генерируется непосредственно из Заказа на покупку. Возвращенный товар помещается на склад. | ||
| Оформить поступление товара | ||
| Продавец оформляет пришедший товар. Он привязывает его по номеру к Заказа на поставку, пишет комментарии к посылке. | ||
| Создать счет-фактуру | ||
| Продавец генерирует Счет-фактуру из Заказа на покупку если на складе есть товар для него. При этом система связывается с интерфейсом перевозчика для получения номера посылки и наклейки на посылку. | ||
| Просмотреть список запросов поставщику | ||
| Заказчик может просмотреть историю продаж товара. | ||
| Искать товар | ||
| При заполнении Предложения Продавец ищет необходимый товар на складе и у заказчиков, выбирая лучшие предложения. | ||
| Менеджер | Назначить ответственного за запрос | |
| Менеджер уведомляется о новых запросах из web, просматривает их и назначает их Продавцу. | ||
| Авторизовать предложение | ||
| Менеджер уведомляется о новых Предложениях, просматривает их, отправляет Продавцу распоряжения по дальнейшей обработке – комментарии по доработке или позволить отправить Quote заказчику. | ||
| Авторизовать заказ на покупку | ||
| Менеджер уведомляется о новых Заказах о покупке. Менеджер авторизует перед тем, как он будет обрабатываться дальше. Продавцу отправляются замечания по Заказу на покупку или разрешение продолжать составление Заказа на поставку, Упаковочный лист, Счет-фактуру и Посылку | ||
| Авторизовать заказ на поставку | ||
| Менеджер уведомляется о новых Заказах на поставку. Он авторизует их для того, чтобы Продавец смог отправить его. | ||
| Просмотреть отчет по всем продажам | ||
| Просмотреть отчет по всем клиентам | ||
| Просмотреть отчет по всем поставщикам | ||
| Просмотреть отчет о прибылях | ||
| Экспорт данных | ||
| Менеджер может экспортировать данные о продажах в Excel или CSV. | ||
| Загрузить подпись | ||
| Менеджер должен загрузить ЭЦП в систему для э-подписи документов. | ||
| Авторизовать акт о возврате | ||
| Акты должны быть авторизованы менеджером перед уведомлением заказчику. | ||
| Импортировать данные | ||
| Товары в Inventory могут быть добавлены импортом из специального Excel файла или CSV. | ||
| Управлять продавцами | ||
| Менеджер управляет Продавцами, привязывая Продавцам к запросам, Территории продаж. | ||
| Просмотреть список всех запросов клиентов | ||
| Менеджер просматривает все запросы заказчиков, отнесенные и не отнесенные автоматически Продавцам. | ||
| Просмотреть список всех предложений | ||
| Просмотреть список всех заказов на поставку | ||
| Клиент | Запросить товар | |
| Заказчик ищет товар через веб-интерфейс. Поиск осуществляется сначала в Inventory, затем через XML-шлюз. Результаты поиска из разных источников должны различимы заказчиком. Поиск может осуществляться по нескольким элементам. По умолчанию предлагается поиск одного товара, с помощью «Добавить» можно увеличить количество искомых товаров. | ||
| Подтвердить предложение | ||
| Заказчик подтверждает Предложение, составленное Продавцом | ||
| Поставщик | Импортировать информацию о себе | |
| Заказчик импортирует информацию о себе через специальный Excel файл или CSV | ||
| Импортировать данные о товаре | ||
| Поставщик импортирует список своих товаров в ESS через специальный Excel или CSV файл. |
В описании прецедентов выявляются сущности системы и их атрибуты для построения даталогической модели системы и создания базы данных.
1.2
1.3
О методе оценки
Стоимостная оценка – это оценка вероятной стоимости тех ресурсов, которые потребуются для выполнения работ, предусмотренных проектом.
Стоимостные оценки рассчитываются в течение всего проекта. Для того чтобы дать проекту разрешение на старт, необходимо вначале проверить концептуальные (предпроектные) оценки его стоимости. На этом этапе используется предварительная оценка, так называемая оценка «порядка величины» (order of magnitude estimate), отличие которой от реальной стоимости лежит в интервале от –25% до + 75%. По ходу реализации проекта требуются более точные оценки. При этом определение сметной стоимости (budget estimates) производится с точностью от –10% до +25%. И наконец, к моменту выработки согласованной базовой цены проекта (project cost baseline) необходимо провести окончательную стоимостную оценку (definitive estimate), значение которой не должно быть меньше реальной более чем на 5% и превышать ее более чем на 10%.
На ранних стадиях проекта неопределенность в понимании реального объема работ проекта еще слишком велика, и нет никакого смысла в затратах усилий на то, чтобы на каждой стадии проекта делать более точные стоимостные оценки, чем это необходимо на текущий момент.
Часто бывают случаи, когда проекты, не завершаются в срок, превышают бюджет или сдаются с недостаточной функциональностью для того, чтобы системой можно было пользоваться. Основными источниками этих печальных результатов являются:
§ Плохое управление проектом
§ "Плывущие" требования
§ Неправильная оценка проекта
Адекватная оценка стоимости проекта важна как для заказчика, так и для исполнителя проекта.
В плывущих требованиях есть одна большая истина - информационная система должна отвечать потребностям заказчика. Причины изменения требований достаточно ясны:
§ Постепенное понимание заказчиком того, что же ему на самом деле нужно
§ Изменение бизнеса заказчика за время реализации проекта
Но понятны и негативные следствия плывущих требований.
Основные причины неправильной оценки проекта:
§ Отсутствие опыта или методики оценки проекта
§ Непонимание ключевых технических проблем проекта
§ Непредвиденные проблемы в используемых средствах и компонентах
Естественно, все вышеописанные проблемы в первую очередь упираются в деньги. А раз в деньги, то, значит, и в контракты, по которым эти деньги выплачиваются (или, не выплачиваются). Значит, важно составить контракт так, чтобы обе стороны выигрывали. При этом, на наш взгляд, вопрос упирается в единицу измерения контракта.
Наиболее популярные единицы измерения - время и проект.
Если в качестве единицы измерения используется время, то оплата исполнителю, как правило, производится регулярно (например, раз в месяц или раз в две недели). Преимуществом такого способа является то, что исполнитель не связан рамками контрактных стоимостей и запросы покупателя выполняются без вопросов и не вызывают пререканий (любые желания за ваши деньги). Недостатками является то, что все риски на покупателе.
Если в качестве единицы измерения используется проект, то оплата производится после окончания значимых этапов проекта. Преимуществом такого способа является то, что бюджет заказчика четко определен, или, по крайней мере, четко отслеживается. Недостатками является то, что все риски на исполнителе, он стремится ограничить функциональность и изменения.
Ввиду всего вышесказанного, хотелось бы иметь единицу измерения проекта такую, которая:
§ непрерывно зависит от сложности проекта и позволяет изменять оценку размера проекта с изменением требований;
§ позволяет распределить риски по-честному;
§ прилагаема на всех стадиях жизненного цикла системы, причем на различных этапах жизненного цикла проекта его эффективность определяется заново, с различной глубиной проработки;
§ давала бы независимые оценки времени выполнения проекта и его трудоемкости;
Система оценки трудозатрат разработана в фирме Инрэко ЛАН с учетом существующих и используемых на практике методов оценки, а так же проанализировав опыт создания программных продуктов.
Процесс оценки
Методика оценки трудозатрат на разработку была разработана с учетом мирового опыта и опыта компании-разработчика. Экспертами для создания коэффициентов и значений временных затрат выступили руководители проектов компании разработчика.
В процессе оценки трудозатрат задействованы следующие роли сотрудников:
· заказчик;
· директор;
· ответственный.
Один сотрудник может выполнять сразу несколько ролей.
Процесс оценки трудозатрат на выполнение проекта выглядит следующим образом:
1. В фирму поступает технико-коммерческое предложение (ТКП) от потенциального заказчика.
2. Директор назначает ответственного за оценку полученного ТКП. Ответственный выбирается из числа сотрудников, с учётом его опыта, специализации и текущей загрузки.
3. Директор высылает письмо с исходными документами и комментариями ответственному.
4. В течение одного рабочего дня директор вместе с ответственным определяют сроки выполнения оценки, директор сообщает дату и время подготовки оценки заказчику.
5. Ответственный определяет трудозатраты на разработку проекта по алгоритму, описанному в п. Ошибка! Источник ссылки не найден. настоящего документа. Оценка оформляется в виде сводного Excel-отчёта и высылается директору.
6. Директор корректирует оценку ответственного с учётом накопленного фирмой опыта и аналогичных продуктов/услуг.
7. Директор отправляет окончательную оценку потенциальному заказчику, проводит согласование и, при необходимости, инициирует коррекцию оценки.
Принятая схема оценки трудозатрат на выполнение проекта основана на прецедентах (use cases).
Алгоритм оценки выполняется ответственным. Выполнение некоторых шагов может быть перепоручено аналитику или разработчику. Алгоритм выглядит следующим образом:
1. Выделить из требований заказчика как можно более полный и точный список прецедентов. Для каждого прецедента необходимо сделать уточнения или составить сценарии до такой степени, чтобы можно было оценить сложность прецедента. Для уточнений требований к системе ответственный организует дополнительную переписку с заказчиком.
2. Оценить каждый прецедент по 5-балльной шкале: 1 – очень простой, 2 – простой, 3 – средний, 4 – сложный, 5 – очень сложный, предполагая реализацию прецедента на платформе .NET, языке С# и СУБД Microsoft SQL Server 2005.
3. Вычислить временную оценку реализации прецедента в соответствии с таблицей. В оценку прецедента входят все стандартные виды работ над программным продуктом: анализ, проектирование (архитектура), разработка, тестирование. Данная оценка включает минимальную документацию необходимую при разработке: прототипы интерфейсов, описания прецедентов, описание архитектуры системы.
Табл. 5.1 – Время реализации прецедентов, чел-час
| Ранг прецедента | Обычный бизнес-прецедент | Научный прецедент |
4. Произвести поправку на технологии. Если проект требует использования других технологий (отличных от использованных при ранжировании прецедентов), то временная оценка прецедента корректируется по таблице коэффициентов сложности технологий и платформ (таблица).
Табл. 5.2 – Коэффициенты сложности технологий и платформ
| Технология и платформа | Коэффициент сложности |
| Java (настольное приложение) | 1,1 |
| J2EE | 1,2 |
| AJAX | 1,5 |
5. Оценить трудозатраты на руководство проектом. Как правило, руководство проектом составляет 25% от оценки на разработку и тестирование. Но данный процент может быть скорректирован в зависимости от характера проекта.
Исходя из полученной продолжительности проекта, можно рассчитать количество специалистов, которые потребуются для выполнения проекта.
6. Учесть дополнительные расходы, которые могут потребоваться в ходе выполнения проекта. Такими могут быть: командировки к заказчику, развертывание приложения, подготовка дополнительной документации и т.п.
7. Определить список рисков, которые могут повлиять на оценку проекта, и указать коэффициенты, которые применятся к итоговой оценке на разработку и тестирование. В рисках не учитываются внутренние риски компании. Примеры рисков и приблизительных коэффициентов приведены в Табл. .
Табл. 5.3 – Коэффициенты рисков
| Риск | Коэфф. |
| Использование внешних систем с неизвестной или нечёткой спецификацией | 1,05-1,1 |
| Использование специализированного оборудования | 1,05-1,1 |
| Использование специализированного оборудования на стороне заказчика | 1,1-1,2 |
Расчет трудоемкости создания проекта
Применим разработанную методику и рассчитаем количество часов и стоимость разработки системы. Для этого будем использовать прецеденты, выявленные на стадии анализа.
При описании прецедентов была определена сложность каждого прецедента. Она и будет использоваться для расчета трудозатрат.
Табл. 5.4 – Список прецедентов для оценки трудоемкости
| Актер | Прецедент | Сложность |
| Общие | Запросить пароль | |
| Пройти аутентификацию | ||
| Администратор | Установить серверную часть | |
| Установить клиентскую часть | ||
| Управлять пользователями | ||
| Управлять статьями помощи | ||
| Экспортировать данные | ||
| Управлять профилем компании | ||
| Продавец | Просмотреть список запросов Управлять запросами | |
| Управлять предложениями | ||
| Управлять списком заказов на покупку | ||
| Управлять списком заказов на поставку | ||
| Просмотреть список товаров на складе | ||
| Просмотреть информацию о товаре | ||
| Просмотреть список клиентов | ||
| Создать акт возврата | ||
| Оформить поступление товара | ||
| Создать счет-фактуру | ||
| Просмотреть список запросов поставщику | ||
| Искать товар | ||
| Менеджер | Назначить ответственного за запрос | |
| Авторизовать предложение | ||
| Авторизовать заказ на покупку | ||
| Авторизовать заказ на поставку | ||
| Просмотреть отчет по всем продажам | ||
| Просмотреть отчет по всем клиентам | ||
| Просмотреть отчет по всем поставщикам | ||
| Просмотреть отчет о прибылях | ||
| Экспорт данных | ||
| Загрузить подпись | ||
| Авторизовать акт о возврате | ||
| Импортировать данные | ||
| Управлять продавцами | ||
| Просмотреть список всех запросов клиентов | ||
| Просмотреть список всех предложений | ||
| Просмотреть список всех заказов на поставку | ||
| Клиент | Запросить товар | |
| Подтвердить предложение | ||
| Поставщик | Импортировать информацию о себе | |
| Импортировать данные о товаре |
Фирма-разработчик является официальным сертифицированным партнером Microsoft, в течение уже долгого времени использует ее технологии и продукты. Выбранные СУБД и среды разработки закупать дополнительно не требуется. Серверы фирмы и рабочие места разработчиков содержат все необходимое программное и аппаратное обеспечение для работы над созданием приложения
В соответствии с предусмотренной методикой таблицей рассчитаем количество человеко-часов, требуемых на реализацию проекта. Заметим, что указанное в таблице время учитывает не только непосредственную разработку, то есть написание кода, но и работу аналитика, архитектора, тестировщика и временные затраты на документирование требований и изменений.
18*30+15*60+7*60=2820
Требуемые технологии являются в данном случае стандартными для фирмы-разработчика, и поэтому коэффициента на технологии вводить не будем.
Добавим затраты на менеджмент проекта. Как было сказано, они составляют 25% от времени на тестирование и разработку.
2820*1,25=3525 чел.-час.
Из описанных рисков существует один, который необходимо учесть – это интеграция с внешними системами компаний-перевозчиков. Поэтому поправим полученный результат на коэффициент риска.
3525*1,1=3880 чел.-час.
Итак, мы рассчитали, что на реализацию заявленной на данном этапе функциональности системы требуется 3880 человеко-часов. Из этой цифры можно получить стоимость разработки, зная часовую ставку специалиста-разработчика. В процессе задействованы разные специалисты, аналитики, разработчики, архитекторы тестировщики и руководители проектов. Будем считать, что их средняя часовая ставка одинакова. Если оплата труда этих работников существенно различается то необходимо вводить коэффициенты участия того или иного специалиста в разработке. Например, если анализ занимает 20% времени, для получения затрат на аналитику необходимо выделить 20% от полученной суммы и умножить на часовую ставку аналитика и затем проделать такую операцию с каждым участником процесса создания приложения.
Таким образом, при среднечасовой ставке работника 80 рублей получается, что стоимость разработки приложения:
3880*80= 310 400 рублей
Так как создание приложение является заказным, то разработчик не участвует в судьбе приложения после его сдачи заказчику и он, в свою очередь, принимает решение о том, как его в дальнейшем использовать. Стоимость продукта так же предстоит определить ему с учетом планируемого количества копий продаж и желаемой прибыли.