'

Техническое Задание: краеугольный камень разработки веб-проекта. Александр Асафов

Понравилась презентация – покажи это...





Слайд 0

http://www.aist.ru | info@aist.ru Техническое Задание: краеугольный камень разработки веб-проекта. Александр Асафов


Слайд 1

Терминология Техническое Задание — документ, возникающий на стадии проектирования, согласованный всеми сторонами, участвующими в разработке. Проект - веб-сайт, веб-ориентрованная информационная система, интранет-система — на всех стадиях разработки до момента запуска. “Хороший проект” - сделан в срок, в полном объеме, соответствие первоначальным ожиданиям Заказчика –-> 100%, бюджет проекта соответствует запланированному. «Плохой проект» - сдан с задержками, не сдан совсем, не соответствует ожиданиям Заказчика полностью или в части, бюджет значительно превышен.


Слайд 2

Плохой проект Последствия плохого проекта:


Слайд 3

Почему проект – плохой? Причины: Появление новых идей в процессе работы над проектом. Изменились требования к стилю, функциональности, структуре. Изменились цели проекта и базовые требования Смена менеджера/руководителя и так далее. Подобные изменения могут появляться в процессе разработки многократно. Следствия: Увеличение времени разработки или незавершенный проект. Разрастание неэффективных затрат на разработку, убытки. Неоптимальные методы решения новых задач. и так далее.


Слайд 4

В чем основная ошибка? Ответ прост: У проекта вообще не было технического задания. ТЗ было, но недостаточно подробное и формализованное. Оно было составлено, по существу, для отписки, «чтоб было». ТЗ есть, но Заказчик или Исполнитель игнорируют его.


Слайд 5

Чем поможет ТЗ? Большинство проектов начинаются тогда, когда и у Заказчика, и у Исполнителя еще нет полного представления о будущем проекте. Техническое Задание позволяет вам понять и формализовать на бумаге все ключевые вопросы. Достаточно часто в процессе составления Технического Задания проект меняется наполовину от того, как себе представлял его Заказчик изначально. Исправить ТЗ до начала разработки – нетрудно. Менять проект в процессе его разработки – намного дольше и сложнее. Это прямой путь к провалу проекта. Прежде чем подписывать ТЗ, убедитесь, что у Вас с разработчиком схожее понимание того, что должно получиться на выходе. Если ТЗ подписано, сайт должен разрабатываться в строгом соответствии с ним.


Слайд 6

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


Слайд 7

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


Слайд 8

Предварительная оценка Большинство заказчиков желает сразу узнать, сколько будет стоить проект. Как правило, точная финальная оценка может быть предоставлена только после подготовки полного ТЗ. Обратите внимание! Если Вам называют точные/ неизменные цифры по стоимости и срокам проекта до: а) изучения полученного описания; б) разработки полноценного Технического Задания — то скорей всего: Разработчик называет заведомо завышенные цифры с учетом заложенных рисков; Дополнительные средства/сроки будут запрошены от вас в процессе разработки, а изначально низкая стоимость является лишь рекламным ходом; Разработчик не имеет достаточного профессионализма для грамотной оценки проекта.


Слайд 9

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


Слайд 10

Пример прототипа Прототип сайта конференции www.Site-2009.ru


Слайд 11

Результат оформления по прототипу Дизайн сайта конференции www.Site-2009.ru


Слайд 12

Пример структуры простого ТЗ (1) 1. ОБЩИЕ СВЕДЕНИЯ О ПРОЕКТЕ 4 1.1. Назначение Технического задания 4 1.2. Основные цели проекта 4 1.2.1. Основные категории посетителей (сайта и конференции) 5 1.3. Графическое оформление 5 1.4. Совместимость с браузерами 6 1.5. Система управления контентом NetCat 6 1.5.1. Аппаратные требования к размещению 6 1.5.2. Архитектура сайта в системе NetCat 7 2. МАКЕТ ТИПОВОЙ СТРАНИЦЫ 13 2.1. Схематический вид 13 2.1.1. Главное навигационное меню 13 2.1.2. Навигационное меню по категориям посетителей 14 2.1.3. Навигация по подразделам 14 2.1.4. «Шапка» страницы 14 2.1.5. Правая колонка 15 2.1.6. Footer страницы 15


Слайд 13

Пример структуры простого ТЗ (2) 3. СТРУКТУРА САЙТА И ОПИСАНИЕ СТРАНИЦ 16 3.1. Обобщенная структура сайта 16 3.2. Описание страниц сайта 16 3.2.1. Главная страница 16 3.2.2. Страница «О конференции» 17 3.2.3. Раздел «Новости» 17 3.2.4. Раздел «Программа» 17 3.2.5. Раздел «Регистрация» 22 3.2.6. Раздел «Выставка» 24 3.2.7. Раздел «Место проведения» 24 3.2.8. Раздел «Контакты» 25 3.2.9. Раздел «Слушателям» 25 3.2.10. Раздел «Докладчикам» 25 3.2.11. Раздел «Журналистам» 25 3.2.12. Раздел «Партнерам» 26 3.2.13. Карта сайта 26


Слайд 14

Пример структуры простого ТЗ (3) 4. ОПИСАНИЕ ФУНКЦИОНАЛЬНЫХ ЭЛЕМЕНТОВ 27 4.1. Новости 27 4.2. Динамическое расписание докладов 27 4.2.1. День конференции 27 4.2.2. Секция конференции 28 4.2.3. Список докладчиков 29 4.2.4. Отдельный доклад 29 4.2.5. Мероприятие вне секций 30 4.3. Голосование 30 5. ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ 31 5.1. Языковые версии и наполнение сайта 31 5.2. Документирование системы 31 ДЕТАЛЬНАЯ СМЕТА 32 ТЗ на достаточно несложный и логичный проект содержит более тридцати страниц, и не может быть ограничено документом в несколько страниц. ТЗ на более сложный проект — соответственно, гораздо подробней.


Слайд 15

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


Слайд 16

http://www.aist.ru | info@aist.ru Спасибо! Александр Асафов (495) 783-6021 a.asafov@aist.ru


×

HTML:





Ссылка: