Разработка web-ресурса - Курсовая работа

Техническое задание, сокращенно ТЗ, уже довольно давно служит для формального описания того, что мы хотим видеть в конечном продукте. На примере мы разберем ТЗ для разработки web-ресурса. ТЗ, как правило, прилагается к основному договору на работы по созданию web-ресурса, т. к. включает полный перечень всех работ для обязательного выполнения дабы исключить возможные споры между клиентом и исполнителем, которые, как известно все-равно время от времени возникают.Среди возможных вариантов можно назвать ТЗ, описывающее главные страницы интерфейса со всей совокупностью элементов на ней и описанием их поведения. В ТЗ для программиста не должен упоминаться дизайн элементов или звучать пожелания по дизайну. Для несложных сайтов, где нужно описать какой-нибудь функциональный модуль, нужно проанализировать сайты с похожим функционалом, провести анализ конкурентов; сохранить гиперссылки на страницы с требуемыми элементами интерфейса и функциями, и включить их в ТЗ с расширенными пояснениями о том, что именно делать.Одна из возможных структур сайта, может выглядеть так: 1.Здесь достаточно несколько предложений для того что бы ввести в курс дела, что за сайт или модуль будет разрабатываться и его цель в общем. Тут краткий перечень того, какими техническими средствами или инструментами должен обладать сайт, исходя из общей цели. Этот раздел включает список модулей, которые используются на сайте. Например, список браузеров, где сайт должен корректно отображаться и работать. Некоторые заказчики могут требовать, чтобы их сайт работал корректно в Internet Explorer, чтобы не терять долю возможных посетителей.Результатом анализа требований является получение спецификации разрабатываемого ПО, т.е. выполняют декомпозицию и содержательную постановку решаемых задач, уточняют их взаимодействие и эксплуатационные ограничения.Функциональные спецификации описывают функции ПО, а эксплуатационные определяют требования к техническому средству, надежности, информационной безопасности и т.д. Означает, что спецификации должны однозначно восприниматься заказчиком и разработчиком. Формальные модели на этапе определения спецификации делят на 2 группы: 1. модели, зависящие от подхода к разработке (структурного или объектно-ориентированного) В рамках структурного подхода на этапе анализа и определения спецификации используют 3 типа моделей: 1. ориентированные на функции, 2. ориентированные на данные, 3. ориентированные на потоки данных. Методология структурного анализа и проектирования, основанные на моделировании потоков данных, обычно используют комплексное представление проектируемого ПО в виде совокупности моделей: 1. диаграммы потоков данных DFD(DATAFLOWDIAGRAMS) описывает взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе.Отражают взаимосвязи функций разрабатываемого ПО. Отображение взаимосвязи функций активностной модели осуществляется путем построения иерархии функциональных диаграмм.Систему представляют в виде иерархии диаграмм потоков данных, описывающих асинхронный процесс преобразования информации с момента ввода до выдачи результатов. В основе модели лежат понятия внешней сущности процесса - хранилище и потока данных.Структуры данных-это совокупность правил и ограничений, которая отражает связи между элементами данных. Различают абстрактные структуры данных (для уточнения связи между элементами) и конкретные структуры для предоставления данных в программах. Во втором случае существенными являются не только вхождения элемента в некоторую структуру, но и порядок, а также отношение иерархии структур (т.е. вхождение в структуру более высокой степени общности).Она используется в тех случаях, если отношение между компонентами данных не исчерпываются включением. Для графического представления разновидностей этой модели используется несколько нотаций.Процесс проектирования сложного программного обеспечения начинают с уточнения его структуры, т. е. определения структурных компонентов и связей между ними. Результат уточнения структуры может быть представлен в виде структурной и/или функциональной схем и описания (спецификаций) компонентов. Структурной называют схему, отражающую состав и взаимодействие по управлению частей разрабатываемого программного обеспечения. Структурные схемы пакетов программ не информативны, поскольку организация программ в пакеты не предусматривает передачи управления между ними. Структурными компонентами программной системы или программного комплекса могут служить программы, подсистемы, базы данных, библиотеки ресурсов и т. п.Структурный подход к программированию в том виде, в котором он был сформулирован в 70-х годах XX в., предлагал осуществлять декомпозицию программ методом пошаговой детализации. Метод пошаговой детализации реализует нисходящий подход и базируется на основных конструкциях структурного программирования.

Оглавление

1. Разработка технического задания

1.1 Общие рекомендации по написанию ТЗ

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

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

2.1 Спецификации ПО при структурном подходе.

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

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

2.4 Структуры данных и диаграммы отношений компонентов данных.

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

3. Проектирование программного обеспечения при структурном подходе

3.1 Разработка структурной и функциональной схем.

3.2 Использование метода пошаговой детализации для проектирования структуры программного обеспечения.

3.3 Структурные карты Константайна.

3.4 Проектирование структур данных.

4. Методы объектно-ориентированного анализа и проектирования программного обеспечения. Язык моделирования uml

5. Разработка прототипа программного обеспечения

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

6. Проектирование интерфейса пользователя

7. Объектно-ориентированное программирование(ооп)

8. Выбор стратегии тестирования и разработка тестов

Вывод

1. Разработка технического задания