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

Анализ исходных и результатных данных

Рассмотрим входные и выходные данные системы и их реквизиты, определенные на этапе выяснения требований к функциям системы в таблицах 2.1 и 2.2.

Таблица 2.1 – Исходные данные.

Документ	Реквизиты	Комментарий
Запрос	Запрашиваемый товар	Наименование запрашиваемого товара
	Цена за единицу
	Ответственный за исполнение	Сотрудник фирмы, ответственный за рассмотрение запроса. Назначается менеджером или автоматически в соответствии с предопределенными правилами
	Дата создания
	Статус
	Комментарии
Продолжение Таблицы 2.1– Исходные данные.
	Количество
	Создатель	Указывается сотрудник компании, создавший запрос вне веб-интерфейса
	Изменено	Кто из сотрудников последним корректировал запрос
	Контактное лицо	Контактное лицо компании-клиента, создавшее запрос
Информация о поставщике	Наименование фирмы
Телефон
Факс
Адрес электронной почты
Адрес сайта компании
Товары и цены поставщиков
Информация о покупателе	Наименование фирмы
Телефон
Факс
Адрес электронной почты
Адрес сайта компании
Информация о посылке	Наименование компании-перевозчика
Заказ на покупку	Указывается связь посылки и заказа на покупку, по которому отправляется товар
Номер посылки	Главный реквизит, обеспечивающий отслеживание статуса посылки и ее идентификацию

Таблица 2.2 – Результатные данные.

Заказ на поставку	Наименование компании поставщика
Наименование товара
Цена за единицу закупаемого товара
Комментарии
Дата создания
Дата изменения
Кто создал	Указывается сотрудник компании, создавший заказ на поставку вручную
Кто редактировал	Кто из сотрудников последним корректировал запрос
Информация о посылке	Наименование компании-перевозчика
Заказ на покупку	Указывается связь посылки и заказа на покупку, по которому запрашивается товар
Номер посылки	Главный реквизит, обеспечивающий отслеживание статуса посылки и ее идентификацию

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

Варианты использования

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

Для того чтобы более точно понять как должна работать система, все чаще используется описание функциональности системы через варианты использования (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 шлюза. При ошибках – откат установки.
	Управлять пользователями
	При первом запуске серверного приложения администратор создает пользователей, объединяет их в группы. Для Менеджера кроме прочей информации указывается его Территория продаж. Продавец подотчетен Менеджеру.
Продолжение Таблицы 2.3 – Описание прецедентов и их сложность
	Управлять статьями помощи
Пользователи имеют доступ к помощи по работе с приложением, часто задаваемым вопросам. Администратор должен иметь возможность редактировать эту информацию через удаленное веб-приложение или из БД.
Экспортировать данные
Экспорт в Excel или CSV таблиц поставщиков, заказчиков…
Управлять профилем компании
При первом запуске администратор создает профиль компании с указанием параметров. Эти значения могут быть изменены в любой момент из клиентского приложения пользователем, у которого на это есть разрешение администратора.
Продавец	Просмотреть список запросов Управлять запросами
Продавец может создавать запрос вручную, изменять статус запросов, редактировать запросы.
Управлять предложениями
Продавец рассматривает Требование и составляет Предложение. При этом он имеет доступ к информации об имеющихся у поставщиков товарах. Предложение может подтверждаться Менеджером, а затем отправляется Клиенту.
Управлять списком заказов на покупку
Клиент отвечает на Подтверждение предложения подтверждением номера Предложения и сроком оплаты, если возможно. Осуществляется поиск Предложения. Для найденного Предложения возможно создать Заказ на покупку.
Управлять списком заказов на поставку
Для утвержденного Заказа на покупку можно сгенерировать Заказ на поставку. Заказ на поставку также можно создать вручную для пополнения склада. Заказы на поставку могут создаваться из Предложений поставщиков. В любом случае перед посылкой Заказа на поставку он утверждается Менеджером
Продолжение Таблицы 2.3 – Описание прецедентов и их сложность
	Просмотреть список товаров на складе Просмотреть информацию о товаре Просмотреть список клиентов
Пользователь должен иметь возможность отправить уведомление о том, что запрошенные товары имеются в наличии. Для этого пользователь должен знать, кто заказывал товар. Выбрав товар, пользователь может просмотреть незаконченные заказы по ним. Пользователь должен иметь возможность просмотреть данные о товаре, открыв PDF документ
Создать акт возврата
Пользователь проверяет номер возвращенного товара, содержимое возвращенного пакета, причину возврата. Генерируется непосредственно из Заказа на покупку. Возвращенный товар помещается на склад.
Оформить поступление товара
Продавец оформляет пришедший товар. Он привязывает его по номеру к Заказа на поставку, пишет комментарии к посылке.
Создать счет-фактуру
Продавец генерирует Счет-фактуру из Заказа на покупку если на складе есть товар для него. При этом система связывается с интерфейсом перевозчика для получения номера посылки и наклейки на посылку.
Просмотреть список запросов поставщику
Заказчик может просмотреть историю продаж товара.
Искать товар
При заполнении Предложения Продавец ищет необходимый товар на складе и у заказчиков, выбирая лучшие предложения.
Менеджер	Назначить ответственного за запрос
Менеджер уведомляется о новых запросах из web, просматривает их и назначает их Продавцу.
Продолжение Таблицы 2.3 – Описание прецедентов и их сложность
	Авторизовать предложение
Менеджер уведомляется о новых Предложениях, просматривает их, отправляет Продавцу распоряжения по дальнейшей обработке – комментарии по доработке или позволить отправить Quote заказчику.
Авторизовать заказ на покупку
Менеджер уведомляется о новых Заказах о покупке. Менеджер авторизует перед тем, как он будет обрабатываться дальше. Продавцу отправляются замечания по Заказу на покупку или разрешение продолжать составление Заказа на поставку, Упаковочный лист, Счет-фактуру и Посылку
Авторизовать заказ на поставку
Менеджер уведомляется о новых Заказах на поставку. Он авторизует их для того, чтобы Продавец смог отправить его.
Просмотреть отчет по всем продажам
Просмотреть отчет по всем клиентам
Просмотреть отчет по всем поставщикам
Просмотреть отчет о прибылях
Экспорт данных
Менеджер может экспортировать данные о продажах в Excel или CSV.
Загрузить подпись
Менеджер должен загрузить ЭЦП в систему для э-подписи документов.
Авторизовать акт о возврате
Акты должны быть авторизованы менеджером перед уведомлением заказчику.
Импортировать данные
Товары в Inventory могут быть добавлены импортом из специального Excel файла или CSV.
Управлять продавцами
Менеджер управляет Продавцами, привязывая Продавцам к запросам, Территории продаж.
Продолжение Таблицы 2.3 – Описание прецедентов и их сложность
	Просмотреть список всех запросов клиентов
Менеджер просматривает все запросы заказчиков, отнесенные и не отнесенные автоматически Продавцам.
Просмотреть список всех предложений
Просмотреть список всех заказов на поставку
Клиент	Запросить товар
Заказчик ищет товар через веб-интерфейс. Поиск осуществляется сначала в Inventory, затем через XML-шлюз. Результаты поиска из разных источников должны различимы заказчиком. Поиск может осуществляться по нескольким элементам. По умолчанию предлагается поиск одного товара, с помощью «Добавить» можно увеличить количество искомых товаров.
Подтвердить предложение
Заказчик подтверждает Предложение, составленное Продавцом
Поставщик	Импортировать информацию о себе
Заказчик импортирует информацию о себе через специальный Excel файл или CSV
Импортировать данные о товаре
Поставщик импортирует список своих товаров в ESS через специальный Excel или CSV файл.

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

Процесс оценки

Методика оценки трудозатрат на разработку была разработана с учетом мирового опыта и опыта компании-разработчика. Экспертами для создания коэффициентов и значений временных затрат выступили руководители проектов компании разработчика.

В процессе оценки трудозатрат задействованы следующие роли сотрудников:

· заказчик;

· директор;

· ответственный.

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

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

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.

Табл. 5.3 – Коэффициенты рисков

Риск	Коэфф.
Использование внешних систем с неизвестной или нечёткой спецификацией	1,05-1,1
Использование специализированного оборудования	1,05-1,1
Использование специализированного оборудования на стороне заказчика	1,1-1,2

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

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

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

Табл. 5.4 – Список прецедентов для оценки трудоемкости

Актер	Прецедент	Сложность
Общие	Запросить пароль
Пройти аутентификацию
Администратор	Установить серверную часть
Установить клиентскую часть
Управлять пользователями
Управлять статьями помощи
Экспортировать данные
Управлять профилем компании
Продавец	Просмотреть список запросов Управлять запросами
Управлять предложениями
Управлять списком заказов на покупку
Управлять списком заказов на поставку
Просмотреть список товаров на складе
Просмотреть информацию о товаре
Просмотреть список клиентов
Создать акт возврата
Оформить поступление товара
Создать счет-фактуру
Просмотреть список запросов поставщику
Искать товар
Менеджер	Назначить ответственного за запрос
Авторизовать предложение
Авторизовать заказ на покупку
Авторизовать заказ на поставку
Продолжение Таблицы 5.4 – Список прецедентов для оценки трудоемкости
	Просмотреть отчет по всем продажам
Просмотреть отчет по всем клиентам
Просмотреть отчет по всем поставщикам
Просмотреть отчет о прибылях
Экспорт данных
Загрузить подпись
Авторизовать акт о возврате
Импортировать данные
Управлять продавцами
Просмотреть список всех запросов клиентов
Просмотреть список всех предложений
Просмотреть список всех заказов на поставку
Клиент	Запросить товар
Подтвердить предложение
Поставщик	Импортировать информацию о себе
Импортировать данные о товаре

Фирма-разработчик является официальным сертифицированным партнером Microsoft, в течение уже долгого времени использует ее технологии и продукты. Выбранные СУБД и среды разработки закупать дополнительно не требуется. Серверы фирмы и рабочие места разработчиков содержат все необходимое программное и аппаратное обеспечение для работы над созданием приложения

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

18*30+15*45+7*60=1635 чел-час.

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

Добавим затраты на менеджмент проекта. Как было сказано, они составляют 25% от времени на тестирование и разработку.

1635*1,25=2045 чел.-час.

Из описанных рисков существует один, который необходимо учесть – это интеграция с внешними системами компаний-перевозчиков. Поэтому поправим полученный результат на коэффициент риска.

2045*1,1=2250 чел-час.

Итак, мы рассчитали, что на реализацию заявленной на данном этапе функциональности системы требуется 3880 человеко-часов. Из этой цифры можно получить стоимость разработки, зная часовую ставку специалиста-разработчика. В процессе задействованы разные специалисты, аналитики, разработчики, архитекторы тестировщики и руководители проектов. Будем считать, что их средняя часовая ставка одинакова. Если оплата труда этих работников существенно различается то необходимо вводить коэффициенты участия того или иного специалиста в разработке. Например, если анализ занимает 20% времени, для получения затрат на аналитику необходимо выделить 20% от полученной суммы и умножить на часовую ставку аналитика и затем проделать такую операцию с каждым участником процесса создания приложения.

Таким образом, при среднечасовой ставке работника 80 рублей получается, что стоимость разработки приложения:

2250*80= 180 000 рублей.

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