Здравствуйте!

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

Теория

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

1. Сначала выявляем варианты использования системы.
2. Потом рисуем наброски экрана для всех вариантов использования.
3. Формулируем модель базы данных.
4. Отталкиваясь от набросков экрана, считаем прогноз трудозатрат.
5. Добавляем расходы на непредвиденные дела.

А теперь посмотрим, как это работает на практике. В качестве примера возьмём видеохостинг (это упрощённая версия одного реального проекта).

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

Вариант использования (use case) – это некое действие, который пользователь может сделать с системой, описанное с позиции пользователя (т. е. без технических деталей).

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

Что надо сделать, чтобы выявить варианты использования?

Распечатайте текст, возьмите фломастер и подчеркните в тексте все глаголы.

Каждый глагол – потенциальный вариант использования (а каждое существительное – потенциальная сущность в базе данных). Вот видите – великий и могучий опять помогает нам проектировать ПО

Теперь возьмём наш пример с видеохостингом. Заказчик дал нам следующее описание его желаний:

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

Глаголы я уже выделил жирным шрифтом.

Что дальше?

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

1. Глагол обозначает некую функцию системы, которая точно нужна заказчику (Вы в этом уверены).
2. Глагол обозначает некую функцию системы, но Вы не уверены, что она нужна.
3. Это всего лишь глагол.

Глаголы из первой группы следует поместить в диаграмму, из второй – в список вопросов заказчику, а из третьей – в топку.

Диаграмма вариантов использования

Диаграмма вариантов использования (ВИ) рисуется так:

1. Для каждого ВИ надо нарисовать эллипс.
2. Потом надо нарисовать типы пользователей и соединить линиями тип пользователя и доступные ему ВИ.

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

• гость (незарегистрированный пользователь),
• пользователь,
• модератор,
• администратор,
• верховный администратор.

А диаграмма с вариантами использования выглядит так:

Наброски экранов

Теперь для каждого ВИ надо нарисовать набросок пользовательской оболочки (как это делать, описано здесь).

Это архиважный этап – 90 % заказчиков на этом этапе не имеют вообще никакого понятия о том, как должно выглядеть приложение. Оставшиеся 10 % имеют очень смутное представление.

=> Быстренько набросав эскизы экранов, можно сильно помочь заказчику получить более точное представление о том, что он хочет.

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

Вот как выглядят наброски пользовательской оболочки для нашего видеохостинга:

Модель данных

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

Алгоритм здесь очень простой:

1. Берём любое окошко.
2. Для каждого элемента управления записываем название элемента информации.
3. Определяем сущность, в которой эта информация будет хранится.

Приведу пример. У нас есть набросок входной страницы:

В ней есть текстовые поля «Электронная почта» и «Пароль». Эти элементы информации относятся к сущности «Пользователь».

Ещё пример. В странице для отображения перечня роликов в таблице есть столбцы «Название», «Длительность» и «Дата закачки». Все они являются атрибутами сущности «Ролик» (см. красные эллипсы).

В итоге предварительная модель данных для нашего видеохостинга выглядит так:

Сущность «Пользователь»

1. Электронная почта (текст)
2. Пароль (текст)
3. Фамилия (текст)
4. Имя (текст)
5. Отчество (текст)
6. Количество посещений сайта (целое число)

Сущность «Ролик»

1. Название (текст)
2. Длительность (период времени)
3. Дата закачки (дата)
4. Количество просмотров (целое число)
5. Содержание ролика (двоичные данные)

Приблизительная оценка трудозатрат

Теперь можно прикинуть трудозатраты. Процесс выглядит так:

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

Здесь есть один важный нюанс. Большинство разработчиков не могут внятно дать прогноз трудозатрат, если попросить их одно число (сколько часов тебе понадобится?). Гораздо проще прогнозировать трудозатраты в виде интервала – в лучшем случае мне потребуется полчаса, а если нагрянет Мэрфи – то два. После этого имеет смысл посчитать среднее значение.

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

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

Вывод: Не следует заморачиваться на прогноз трудозатрат с точностью до минуты.

Пример расчёта трудозатрат для входной страницы

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

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

Просто, не правда ли?

Считаем дальше

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

Используя мощные средства современной таблицы умножения к ним надо добавить 30-50 % на непредвиденные работы. Чем больше неопределённостей и чем ниже качество управления, тем более высокий процент надо взять.

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

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

Итог – для реализации прототипа видеохостинга понадобится от 38 до 112 человекочасов.

Следующие шаги

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

Успехов

Дмитрий Писаренко