Часть 4. Проектирование

Техническое

пае задание

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

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

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

Основные разделы документа

Техническое задание должно быть отправной точкой для технического проектирования сайта, оно должно разъяснять все вопросы и не допускать разночтений при осуществлении поставленных задач. Классическое техническое задание на проектирование интернет-сайта как частный случай ТЗ на автоматизированную систему или программное средство содержит следующие разделы:

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

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

в работе, и устанавливаются базовые значения технико-э комических показателей (например, количество одноврем

но обслуживаемых покупателей и их технические возможности по доступу к ресурсу).

3. Характеристики сайта. Здесь описывают условия эксплуатации интернет-сайта; устанавливают ограничения по объему размещаемой в базе данных информации; приводят прогнозы по увеличению функциональных возможностей или из-

Ешв раз о задачах участников составления ТЗ

На этапе подготовки технического задания, как общего — в виде руководства, так и частного — в виде техн ических специфи ка ци и всего и нтернет-сайта или в виде одного модуля, необходимо участие специалистов по системному анализу, архитектуре, графическому пользовательскому интерфейсу и аппаратным средствам. В данный список не включены дизайнеры, которые могут внести свою лепту только в оценку проекта, специалисты по обеспечению качества, в обязанности которых входит подготовка плана по обеспечению качества (Quality Plan). Последний готовится на стадии "Редпроектной подготовки или оценки возможности разработки интернет-сайта, но именно на фазе подготовки технического задания этот план усовершенствуется и внедряются процедуры контроля качества. Для более четкого отображения требований и нужд бизнеса в качестве консультантов на этой фазе выступают представители структурных подразделений компании.

задачи руководителя проекта (менеджера екта) входят:

координация работ; * Фиксация результатов; контроль сроков и возможных затрат.

8 задачи технического руководителя проекта

подготовка шаблонов проектирования; Разработка требований к процессу программирования;

• подготовка стандартов разработки;

• подготовка стандартов управления конфигурацией;

• вовлечение пользователей в процесс разработки технического задания.

Системный архитектор обязан:

• спроектировать систему, которая будет удовлетворять поставленным требованиям, а в случае использования готового продукта разработать схему адаптации этого решения;

• определить стандарты проектирования;

• разработать спецификации, однозначно понимаемые программистами.

Специалист по пользовательским интерфейсам должен:

• сформулировать требования к художественному оформлению;

• определить возможные способы тестирования интерфейсов.

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

Бизнес-консультанты должны утверждать описание требований к системе и ее функциональность.

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

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

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

• требования к интернет-сайту в целом относятся к структуре и функционированию, обслуживанию персоналом, надежности и безопасности, эргономике и технической эстетике, эксплуатации и ремонту, хранению и защите данных от взлома, жизнеспособности при авариях и влиянии внешних воздействий, патентной чистоте, стандартизации и унификации;

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

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

5. Состав и содержание работ по созданию сайта. Здесь описывают перечень стадий и этапов создания интернет-ресурса; сроки выполнения этапов; перечень организаций, принимающих участие в разработке в качестве субподрядчиков; пе речень документов, предъявляемых по окончании кажд°г этапа работ; порядок проведения экспертизы технической Д° кументации; программу работ по обеспечению должног уровня качества и надежности; методические указания пр выполнении особо важных работ.

6. Порядок контроля и приемки работ по созданию саШ11 J Здесь описывают состав, виды, объемы и методы испытай создаваемого ресурса; требования к приемке работ по с

, *г

буемый статус и уровень квалификации участников приемной комиссии.

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

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

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

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

Составляя техническое задание, важно добиться четкого изло-ения требований заказчика в отношении качества, стандартов,

зультатов работы, тестирования, безопасности, условных обо-

ачений, терминов, а также иных параметров, связанных с опре-

лением соответствия производимых работ.

Необходимо понимать, что заказчик и разработчик смотрят

Техническое задание с разных точек зрения: заказчика инте-_ сует внешний вид, функционирование сайта в целом, разра-— возможность пеализаттии

чика. Именно поэтому все термины и понятия, используемы? в документе, должны быть дополнительно разъяснены, а требования к внешнему виду интернет-ресурса до предела формализованы.

ЭСКИЗНЫЙ

И ТЕХНИЧЕСКИЙ ПРОЕКТЫ

Как уже говорилось выше, мы не будем рассматривать возможности прототипирования с использованием CASE-технологий или средств быстрого упрощенного программирования. Если разработчики используют эти средства (готовые продукты или собственные разработки), можно без дополнительной документации получить имитационную модель сайта, которая воочию покажет заказчику принципы работы конечного продукта. Современные CASE-техно-логии позволяют получить необходимую для официального утверждения техническую документацию автоматически: генерация документов осуществляется самой машиной по созданному прототипу. К сожалению, умелое использование таких дорогостоящих технологий в российских компаниях осуществляется далеко не всегда. Поэтому мы рассматриваем традиционный «бумажный» процесс.

В реализации большинства проектов принимают участие различные специалисты, иногда не представляющие реальных возможностей друг друга. Например, дизайнер не всегда может разобраться в архитектуре базы данных, а программисту часто не удается выполнить эскиз дизайнера. Поэтому до того, как начнется программирование, необходимо расширить термин «техническое задание» до термина «спецификация проекта» — документа этапа эскизного и технического проектирования.

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

оазделе «Методика, время и этапы проектирования». Состав и пе-ечень всех специфических документов этапа проектирования (напомним, их около 30), скорее, должны знать технические спе-иалисты, а не менеджер проекта. Кроме того, только крупные про-кты нуждаются в столь тщательном документировании, следовательно, затраты на детальное описание небольшого сайта могут быть избыточными.

Спеиификашш проекта

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

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

Задачами спецификации являются:

• разработка проектных решений по структуре навигации и маршрутам посетителей;

• разработка проектных решений по архитектуре и интерфейсам сайта;

• разработка алгоритмов и функциональной модели взаимодействия данных;

• разработка рабочей документации системы;

• разработка принципов и требований к комплектованию (сборке) отдельных элементов системы друг с другом;

• описание информационного наполнения, информационное проектирование.

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

Основные раздепы спецификации

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

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

• основные технические решения: по организации сайта в целом; по взаимосвязи отдельных программных и функциональных компонентов; по режимам функционирования и диагностики; по численности и квалификации обслуживающего персонала; по способам обеспечения требований ТЗ; по составу задач; по составу информации в базе данных и ее объему; по составу программных средств (языкам проектирования, методикам управления версиями);

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

2. Решения в области структуры и интерфейсов. Здесь приво дят описание возможных действий посетителя сайта и пор док его обслуживания службой поддержки по следуюШй направлениям:

• навигация и маршруты посетителей: исходя из задач технической концепции проектируются переходы по сайту, выявляются навигационные взаимосвязи и алгоритмы удовлетворения потребностей

ТТРЛРИПМ"

• информационные и сервисные возможности посетителей: исходя из требований к информационному наполнению и специфики предметной области разрабатывается структура информационных объектов, порядок их взаимодействия друг с другом, формулируются принципы работы интерактивных и мультимедийных сервисов;

• эскизы типовых страниц сайта: исходя из описания порядка доступа посетителей и принципов работы службы поддержки разрабатываются постраничные эскизы, панели управления и т.д.

3. Решения в области архитектуры и организации базы данных. Здесь описывают логическую и физическую структуру базы данных с точки зрения масштабируемости, конфигурационного управления, независимости работы отдельных элементов друг от друга при сбоях или взломах, останавливаются на следующих вопросах:

• данные: состав, формат записей, взаимосвязи между данными разных частей базы;

• характер взаимосвязей баз данных с указанием функций сайта, при реализации которых используется каждая из них;

• варианты расположения данных на конкретных машинах: распределение базы данных по физическим мощностям и вычислительным ресурсам.

4. Решения в области функциональной структуры. Здесь приводят описание особенностей интернет-сайта, влияющих на проектные решения, сведения об информации, которой он Должен обмениваться с другими системами, информационную модель, автоматизируемые функции, направленные на Достижение целей. Ключевые вопросы:

• характеристика функциональной структуры: перечень подсистем с указанием функций и задач, описание процесса выполнения функций, пояснения по разделению функций на операции (для технических средств и человека), временной регламент и характеристики процессов;

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

5. Решения в области программного обеспечения. Здесь приво дят основные сведения о техническом, информационном и других видах обеспечения, необходимых для разработки программного обеспечения. Здесь говорится:

• о структуре программного обеспечения: приводится перечень частей программного обеспечения с указанием их взаимосвязей и совместимости;

• о функции частей программного обеспечения: дается их назначение и описание;

• о методах и инструментальных средствах разработки программного обеспечения с указанием компонентов сайта, для которых эти методы будут применяться;

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

6. Решения в области информационного обеспечения. Здесь приводят описание состава информационного обеспечения работы сайта с указанием наименования и назначения всех баз и наборов данных. При этом останавливаются на следующих вопросах:

• организация информационного обеспечения: основные принципы, выбор носителей данных и распределение данных по различным типам носителей, описание методов контроля обработки данных при создании и функционировании информационных баз, описание решений по информационной совместимости с другими системами (например, ин-транет) по источникам и потребителям;

• организация сбора и передачи информации: перечень источников и носителей информации с указанием интенсивности и объема потоков данных, описание требований к организации СбОра/ПереДа-

. система классификации и кодирования информации: описание классификации, методик кодирования объектов, разработка системы идентификаторов для информационных материалов.

7 Решения в области алгоритмов работы. Здесь приводят описание процессов и соответствующих им алгоритмов, ограничения и условия применения алгоритмов, характеристики качества решения и требования к входным/выходным данным. Основные вопросы описания каждого алгоритма:

• используемая информация и характеристики: массивы информации, сформированные из входных сообщений, полученные в результате работы других алгоритмов и сохраняемые для реализации данного алгоритма;

• процесс решения: перечень и содержание массивов информации, формируемых в результате реализации алгоритма, математическая модель процесса, перечень допущений, описание логики алгоритма и способа формирования результатов с указанием последовательности и этапов счета, логические и расчетные формулы алгоритма;

• требования к разработке программы: диагностические сообщения при работе с программой, требования к контролю данных в процессе выполнения проектной операции, ограничения машинной реализации, требования к контрольной задаче.

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

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

ТИПИЧНЫЕ ОШИБКИ

Исследования, проведенные институтом Санта-Галлена и Между-НаРодным институтом обучающих организаций и инноваций сре-АИ более чем пятисот сотрудников ста одиннадцати предприятий

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

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

фикации проекта и/или технического задания и исполнитель не может определить все затраты на разработку. При проведении небольших или типичных для исполнителя работ ошибка в сроках и стоимости может составить около 10% от запланированного показателя.Данная погрешность достаточно мала, и ею можно пренебречь. Однако при разработке инновационного решения или проведении сложного проекта просчет в определении суммы контракта может варьироваться в пределах от 30% стоимости разработки, что уже является очень серьезной ошибкой. Способом решения данной проблемы является привлечение исполнителя к консалтингу клиента для составления концепции проекта.

Консультирование клиента и составление концепции его присутствия в Интернете. В концепции проекта описываются задачи сайта и способ их решения. При определении способов решения задач сайта выявляется инструментарий решения задач, что в свою очередь позволяет снизить ошибку оценки сроков и стоимости. Увы, многие исполнители решают собственные ошибки за счет клиента, завышая стоимость заказа либо срывая сроки сдачи проекта. Концепция описывает группы пользователей, на которых должен воздействовать сайт, и способы реализации данного воздействия. При отсутствии четкого определения целевой группы пользователей сайта возможно неправильное определение способов взаимодеи" ствия с ней. В результате интернет-сайт не будет решать поставленные задачи надлежащим образом. Такая ошибка может возникнуть при непра-

Окончание "*

Типичные ошибки

в системе Испопнитепь-Заказчик

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

Возникновение ошибок возможно как со стороны заказчика, так и со стороны клиента. Рассмотрим ряд типичных ошибок в системе Исполнитель-Заказчик. Схема работы исполнителя с заказчиком складывается из нескольких этапов. Я приведу наиболее полную схему.

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

уклонение от написания проектной документации под какими бы то ни было предлогами. Единственная ситуация, в которой ТЗ писать не надо, — ваше решение об отказе от создания сайта;

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

замыкание при составлении проектной документации на технологиях и игнорирование «человеческого фактора» (будущих посетителях, покупателях, партнерах);

Окончание "Т

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

Этап составления спецификации проекта и/или технического задания. Этот этап является непосредственным началом разработки. Спецификация проекта — это описание всего проекта. Здесь необходимо:

• как можно подробнее оценить содержательную составляющую сайта;

• продумать логистику и навигационную систему сайта вплоть до составления постраничной спецификации;

• описать методы коммуникации с аудиторией и их функционирование;

• спланировать процессы обслуживания сайта;

• выявить технологии для реализации составляющих сайта.

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

Типичная ошибка — это составление неполной спецификации в расчете на то, что «я это и так все Знаю, зачем мне это описывать». Составлять спецификацию необходимо, даже если заказчик и исполнитель — одно и то же лицо. Чем подробней °писание, тем меньше вопросов возникает у про-

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

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

Этап реализации. Здесь одной из составляющих успеха проекта является менеджмент проекта в производственных отделах. Менеджер ведет всю разработку и следит за правильностью выполнения всех этапов.

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

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

• излишний акцент на оформление (дизайн). Первостепенную роль на любом коммерческом сайте, даже если это онлайно вая выставка-продажа картин, играет контент (наполнение! быстрый доступ к материалам, контактная информация, опи' сание основных и дополнительных услуг;

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

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

ВЫВОДЫ

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

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

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

НАСТЬ 5

Разработка и тестирование

-> Главное - поэтапньш контроль •* Обратная связь с посетителями •* Компромиссы необходимы везде •* Как оценивать проделанную раЕюту? «* В состав комиссии по приемке входят... -* Устранение недоделок •> Если есть претензии... •* Оформляем и подписываем акт •> Специфические ошибки •* Выводы

ЕСЛИ после проектирования и размещения у подрядчика заказа на создание интернет-сайта вы планировали расслабиться, можете забыть об этом: работа только начинается. В первую очередь вам необходимо требовать от исполнителей строгого соблюдения оговоренных контрактом сроков. Предложения подрядчика сдать работу целиком в подавляющем большинстве случаев неприемлемы. При составлении договора (см. часть 3) вы должны были указать поэтапную сдачу работ, и единственными причинами, которые мо-гут препятствовать соблюдению сроков, являются пожар, наводнение, землетрясение и прочие форсмажорные обстоятельства.

Разработка интерфейсов, кодирование, создание архитекруры Данных неоднократно описывалось в специальной методической литературе. Мы не станем вас утомлять технологическими подробностями — они не для менеджера проекта. В этой части речь пой-AST об основных процессах управления ходом разработки.

Есть расхожее мнение, что, только завершив какую-нибудь ра-

ОТУ, понимаешь, как нужно было ее делать с самого начала. Уже

Процессе изготовления интернет-сайта хочется многое улучшить,

Исправить, изменить. Как в этом случае найти решение, устраи-

вающее и вас, и исполнителей? Ответы на эти вопросы вы найде-

Те в данной части.

ЭТАПЫ РАБОТ

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

Очень трудно рекомендовать какой-то общий алгоритм, поскольку в создании интернет-сайта большое значение имеет специфика решаемой задачи. Порядок работ, ведущихся в соответствии с классическими принципами разработки программного средства по международному стандарту ISO 12207:1995 и отечественному ГОСТ 34.601-90, представлен в табл. 5.1.

Таблица 5.1

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

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

• структуру и содержание исходных и отчетных документов по этапам разработки, испытаний и сопровождения сайта;

• логическую структуру программных и информационных компонентов базы данных;

• спецификации на внутренние интерфейсы компонентов прикладных программных средств и на интерфейсы со внешней средой;

• язык и правила программирования, идентификацию компонентов, комментарии к текстам программ и описаний данных;

• методы тестирования, испытаний и аттестации компонентов и сайта в целом;

• оформление, форматы и обозначения отчетных документов.

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

ПОРЯДОК КОНТРОЛЯ

На сегодняшний день не существует единых стандартов качества для оценки работ по созданию сайтов. Разные компании выходят из этой ситуации по-разному. Одни руководствуются официальными стандартами, другие разрабатывают свою методику, третьи используют CASE-технологии. Между тем контроль качества — одна из ключевых процедур в технологической цепочке разработки интернет-ресурса. Цель такой процедуры — выявление всех возможных ошибок и неточностей в дизайне, верстке и функционировании программного обеспечения. Помочь в осуществлении такого контроля может план реализации, подготовленный при составлении ТЗ, и технологическая документация. Каково содержание этих документов и насколько подробными они должны быть?

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

Не стоит безотрывно наблюдать за исполнителями, это не ускорит процесс разработки. Более того, в вопросах и решениях, напрямую не влияющих на предполагаемый бизнес в Интернете,