Общая структура ТЗ. От абстракции к конкретике

Одна из возможных структур сайта, может выглядеть так:

1. Общая информация о сайте.

2. Функциональное назначение сайта.

3. Понятия и термины

4. Описание модулей сайта

5. Функциональные характеристики

6. Описание страниц.

7. Резервирование и надежность.

8. Хостинг для сайта.

Общая информация о сайте

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

Функциональное назначение сайта

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

Понятия и термины

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

Описание модулей сайта

Этот раздел включает список модулей, которые используются на сайте. Например форма обратной связи (ФОС). Но, что очень важно — нельзя просто писать «Должна присутствовать ФОС». Каждая сущность требует определения своих атрибутов! В данном случае атрибуты могут быть такими:

- Поле «Ваш имя»;

- Поле «Ваш е-mail»;

- Поле «Ваш вопрос»;

- Поле ввода капчи для защиты от спам-роботов.

Функциональные характеристики

Например, список браузеров, где сайт должен корректно отображаться и работать. Некоторые заказчики могут требовать, чтобы их сайт работал корректно в Internet Explorer, чтобы не терять долю возможных посетителей. Если планируется делать высоконагруженный сайт – это тоже нужно указывать. Высоконагруженный сайт требует другого подхода при разработке и по настройке сервера.

Описание страниц сайта

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

Рисунок 1- сайт-каталога

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

Общая структура ТЗ. От абстракции к конкретике - student2.ru

Рисунок 2 - пример прототипа

Остальные страницы

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

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

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

2. Анализ требований и определение спецификации по при структурном подходе

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

Функциональные диаграммы

Отражают взаимосвязи функций разрабатываемого ПО. Пример – активностная модель Д. Росса (1973 г.), он предложил ее в составе методологии SADT(технология структурного анализа и проектирования).

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

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

Диаграмма потоков данных.

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

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

- нотация Йордана,

- нотация Гейна-Сарсона.

Сетевая модель данных.

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

1. нотация П.Чена;

2. нотация Р.Баркера;

3. нотация IDEF1. Более современный вариант этой нотации используется вcase-системах.

Базовыми понятиями сетевой модели данных являются сущность, атрибут и связь.

Создания прототипа.

Быстрое создание прототипа

При быстром прототипировании (англ. rapid prototyping или throwaway prototyping) предполагается, что создаётся макет, который на каком-то этапе будет оставлен («выброшен») и не станет частью готовой системы.

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

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

Быстрое прототипирование не обязательно выполняется в рамках той же платформы и тех же технологий, что и разрабатываемая система. Для прототипа графического интерфейса пользователя (GUI) могут использоваться как стандартные HTML-страницы, либо прототип может подготавливаться в программе, специально предназначенной для создания макетов (например: Axure RP, Microsoft Expression Blend и др.).

Эволюционное создание прототипа

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

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

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

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

Вывод

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