L Формирование высокоуровневых требований к сайту
В списке нужно указать все значимые особенности конечного результата, которыми он должен обладать по завершению проекта.
Высокоуровневыми требованиями можно считать решения в области архитектуры веб-сайта, принципиальных возможностях (функциональных модулях системы управления) или нестандартные детальные требования (например, чтобы веб-сайт имел версию для мобильных устройств). При наличии большого количества требований их можно разбить на группы (наполнение, дизайн, программирование, другие).
Пример таблицы Список высокоуровневых требований к конечному результату проекта
| № | Наименование требования |
| | Требования к сайту: · сайт должен предоставлять пользователям/покупателям возможность просматривать каталоги товаров, а также заказывать выбранные товары; · сайт должен интегрироваться с единой информационной системой компании; · сайт должен обладать удобной системой навигации по сайту и просмотру каталога товаров |
| | Требования к CMS:
|
| | Требования к каталогу интернет-магазина; l Прайс-лист в режиме on-line; l Просто/расширенный поиск по каталогу; l Группировка товаров по типу, алфавиту, фирме-изготовителе; l Формирование корзины товаров. |
| | Требования к разделам сайта: 1. Основные разделы: новости, каталог, рекламные акции, контакты, вакансии |
В эту таблицу не стоит включать подробные развернутые требования по отдельным аспектам проекта, они будут собраны в другой технической документации. Так же как и в случае с целями, нужно по возможности придерживаться критериев SMART. То есть, требования должны быть конкретными, измеримыми и достижимыми. Например, требование «интуитивно понятного интерфейса» не отвечает этим требованиям, потому что не конкретно и субъективно.
l Оценка длительности/трудоемкости операций
Оцените длительность каждой задачи самого нижнего уровня. Данные занесите в столбец «Оценка длительности» таблицы 4.1. «СДР проекта» (структурная декомпозиция работ».
При оценке длительности стоит учитывать реальные сроки реализации этапа с учетом выделенных ресурсов. Например, если обучением пользователей будет заниматься пять человек вместо двух, то длительность процесса резко сократится. При этом трудоемкость не изменится (это будет учтено на следующем этапе оценки ресурсов).
Для повышения точности оценки стоит привлекать нескольких человек и обсуждать результаты. Как показывает практика, коллегиальная оценка обычно точнее, даже если состав оценщиков не однороден с точки зрения профессионализма и знания предмета. Один из методов состоит в использовании ограниченной шкалы оценки (например, используя следующий ряд: 1, 2, 3, 5, 8, 13, 21, 40, 100). После голосования обсуждаются максимальная и минимальная оценки, в результате можно провести второй тур голосования или установить среднюю оценку.
Как известно, оценка длительности этапов является одной из центральных проблем управления проектами (так как обычно сроки проектов срываются). В данной работе точная оценка длительности невозможна, так как нет детальной проработки технического задания и распределения реальных норм по трудоемкости отдельных операций. Однако, даже при подробном расчете срыв сроков является обычным делом, так как причина часто лежит в постоянно изменяющихся требованиях к конечному результату проекта, которые в управлении проектами считаются фиксированными. Это является принципиальным ограничением данной методологии и может быть преодолено с использованием других технологий разработки систем («гибкая разработка» ― agile development).
Пример таблицы СДР проекта
| № 1-го уровня | № 2-го уровня | № 3-го уровня | Название задачи | Оценка длительности/ трудоемкости | Ресурсы* | Оценка стоимости** | |||
| Формулирование концепции | |||||||||
| 1.1. | Определение целей | 1 дн./3 ч | Т1, Т2 | 3300 руб | |||||
| 1.2. | Формирование требований | ||||||||
| 1.2.1 | Подготовка требований | 1 дн./3ч | Т2,Т3 | 2550руб | |||||
| 1.2.2. | Согласование требований | 2ч | Т2, Т1 | 2200руб | |||||
| 2. | Поиск разработчика и подписание договора | ||||||||
| 2.1 | Выбор разработчика | 1 дн/3 ч | Т1, Т2 | 3300 руб | |||||
| 2.2 | Разработка ТЗ | ||||||||
| 2.3.1 | Определение цели, состава и содержания работ | 1 дн/1 ч | Т2, Т4 | 475 руб | |||||
| 2.3.2 | Определение требований к художественному решению | 3 ч | Т2, Т4 | 1425 руб | |||||
| 2.3.3 | Определение функциональных особенностей | 2 ч | Т2,Т4 | 950 руб | |||||
| 2.3.4 | Определение основных требований к функциональности Web-узла | 1 ч | Т2, Т4 | 475 руб | |||||
| 2.3.5 | Определение требований к программным средствам | 1 ч | Т2,Т4 | 475 руб | |||||
| Разработка и запуск Web-узла | 87 000 руб | ||||||||
| 3.1 | Разработка дизайна | ||||||||
| 3.1.1 | Разработка и согласование шаблона главной страницы | 10дн/60 ч | Т3, Т5(1 ч/д) | 2250 руб | |||||
| 3.1.2 | Разработка и согласование шаблона внутренней инф. страницы и страницы каталога | 5 дн/30 ч | Т3, Т5 (1 ч/д) | 1125 руб | |||||
| 3.2 | Автоматизация сайта | ||||||||
| 3.2.1 | Подключение и настройка CMS | 15дн/75 ч | Т6 | ||||||
| 3.3. | Наполнение сайта | ||||||||
| 3.3.1. | Ввод данных в БД | 5дн/40 ч | Т7 | ||||||
| 3.3.2. | Интеграция с 1С | 2дн/16ч | Т7, Т4 | ||||||
| 3.3.3. | Заполнение остальных разделов | 5дн/40ч | Т7, Т4 | ||||||
| 3.4 | Согласование прототипа | 1дн/4ч | Т4, Т2, Т1 | 4400 руб | |||||
| 3.5. | 3.5.1. | Ввод и запуск сайта | 1дн/4ч | Т4 | |||||
| 3.5.2. | Мониторинг и тестирование | 5 дн/30ч | Т4, Т2(4 ч) | 1900 руб | |||||
| 3.5.3. | Исправление ошибок | 5дн/25ч | Т4 | ||||||
| Хостинг | |||||||||
| 4.1 | Поиск хостера | 1 дн/3 ч | Т2 | 950 руб | |||||
| 4.2 | Регистрация домена и перенос сайта | 1 дн/6 ч | Т2 | 500 руб | |||||
| 4.3 | Покупка хостинга | Т2, М1 | 300+9800 руб | ||||||
| Подготовка и оформление всей необходимой документации, завершающих документов,… | 3 дн/12 ч | Т2,Т4 | 5700 руб | ||||||
| Итого проект | 65дней/364 часа | 124 125 руб | |||||||
*- графа «Ресурсы» заполняется на Практическом упражнении №5 «Оценка ресурсов операций».
** - графа «Оценка стоимости» заполняется на Практическом упражнении №7 «Стоимостная оценка проекта». См. файл «Интернет-проект»
РЕЗУЛЬТАТЫ:
Обзор возможных вариантов
Сравнительный анализ разных вариантов (достоинства и недостатки каждого)
Обоснование выбора принятого варианта
Смета затрат
Первоначальные затраты
Операционные затраты
КОМПЕТЕНЦИИ:
В результате выполнения работы студент должен:
ПОНИМАТЬ
· Современные концепции «электронных денег»
· Отличие электронных денег (как разновидности «нефиатных» денег) от фиатных.
УМЕТЬ
· ориентироваться в предложениях платежных систем и платежных агрегаторов
· выбирать оптимальные для решения конкретной задачи формы расчетов в Интернет
· выявлять и оценивать риски
· систематизировать собранную информацию
· передавать наработанные результаты другим группам