МУ_ДЗ_2014 (1079920), страница 16

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

Текст из файла (страница 16)

Все позиции в ТЗ (для ссылок на них) должны быть пронумерованы с помощью многоуровневой нумерации (5.1.1, 5.1.2 и т.д.). В разделах п.7 и п.10 информация может отсутствовать при выполнении ДЗ/КЛР. В раздел 5 могут быть добавлены новые позиции по соглашению с заказчиком (Например, функции защиты информации, безопасность использования программного и технического обеспечения и т.д.).

68 Раздел ТЗ – 5. Технические требования (общее)

В этом разделе ТЗ перечисляются технические требования к программному изделию. Эти требования должны быть выполнены при реализации программного проекта. Формулировки должны быть однозначными. Требования должны быть выполнимы разработчиком и проверяемы заказчиком при проведении приемно – сдаточных испытаниях. В главный раздел могут выноситься требования общего характера, которые должны быть выполнены (Смотрите шаблон и образец ТЗ).

69 Раздел ТЗ – 5.1 Требования к функциональным характеристикам

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

70 Разделы ТЗ – Другие технические требования

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

71 Раздел ТЗ – требования к документации

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

72 Раздел ТЗ – этапы сроки выполнения

Этапы и сроки выполнения ДЗ определяются учебным планом и длительностью семестра. В нашем случае приведенный список этапов и сроков можно сохранить в неизменном виде. Нужно только учесть, что формально ЛР № 12 выполняется в конце семестра, а работу над заданием необходимо начать как можно раньше. Поэтому желательно познакомиться с темой задания и разработать ТЗ в сроки, определенные в образце и шаблоне документа. (Смотрите шаблон и образец ТЗ).

73 Раздел ТЗ – порядок приема и контроля

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

• Проверка принципов построения продукта на макете и ТЗ (ранние стадии).

• Проверка работоспособности продукта – целенаправленно проверяется наличие ошибок в ПО (завершение разработки).

• Проверка документации на соответствие требованиям (завершение разработки).

• Выборочная проверка работоспособности на основе ТЗ и его выполнения, на основе программы и методики испытаний (ПМИ). По завершению разработки.

• Полная комплексная проверка работоспособности и документации на программный продукт. Такая проверка выполняется на основе специального согласованного документа ПМИ.

• Выборочная проверка работоспособности и документации на программный продукт. Такая проверка выполняется на основе специального согласованного документа ПМИ.

В нашем случае (сдача ДЗ студентами) мы выполняем выборочную проверку программ и документации на основе специального документа ПМИ. Для проведения проверки разрабатывается специальный тестовый пример, который позволяет выборочно проверить каждый пункт ТЗ из раздела 5.1 – требования к функциональным характеристикам или, по-другому, функциональным требованиям. Разработка этого примера и документа ПМИ будет рассмотрена в специальной лабораторной работе по курсу. (Смотрите шаблон и образец ТЗ).

74 Порядок изменения и корректировки ТЗ

Документ техническое задание может быть, в порядке исключения, изменен или откорректирован даже после его согласования и утверждения (подписи заказчиком и разработчиком). Для этого разрабатывается отдельный документ с названием: “Корректировка ТЗ”. Далее, после всех согласований документ может быть заново переоформлен либо документ корректировки просто прикладывается к основному ТЗ. Эти действия (переоформление или прикладывание) выполняются по обоюдному согласию разработчика и заказчика.

75 Описание применения

76 Документ описание применения (ОП) ПО и его назначение

Документ “Описание применения” (ОП) программного продукта (данные документ ориентируется на потенциального пользователя ПП и потенциального покупателя ПП). Документ должен отвечать на вопросы, как и при каких условиях можно использовать ПП. Условно можно считать, что данный документ имеет рекламное назначение: прочитав документ, пользователь должен оценить возможности программного продукта и определиться с его приобретением.

77 Стиль изложения ОП

Стиль изложения документа “Описание применения” должен быть описательным ("программа имеет возможности …", "программа работает в среде WINDOWS …", "Система позволяет автоматизировать …", "Объекты, создаваемые на основе классов, обеспечивают построение …" и т.д.). Текст в данном документе должен быть написан ясно, без сложных для понимания технических терминов, простым языком. В случае необходимости в нем оформляются наглядные таблицы и диаграммы. Понимание данного материала должно быть доступно не только для специалистов, а и для менеджеров организаций, для которых предлагается использовать программный продукт.

78 Разработка ОП

Разработка документа ОП выполняется в конце всей разработки программного продукта специалистами по рекламе и по внедрению программного обеспечения. Техническая информация передается им специалистами разработчиками. Основой для разработки ОП является комплект всей документации на ПО.

79 Содержание ОП

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

Содержание документа ОП:

1. НАЗНАЧЕНИЕ ПРОГРАММНОГО ПРОДУКТА

2. ВОЗМОЖНОСТИ ПРОГРАММНОГО ПРОДУКТА

2.1. Общие сведения о программном продукте

2.2. Диаграмма классов программного продукта

3. ОСНОВНЫЕ ХАРАКТЕРИСТИКИ ПРОГРАММНОГО ПРОДУКТА 4. УСЛОВИЯ ПРИМЕНЕНИЯ ПРОГРАММНОГО ПРОДУКТА

4.1. Требования к составу и параметрам технических средств

4.2. Требования к информационной совместимости

4.3. Требования к программному обеспечению

4.4. Требования к условиям эксплуатации

4.5. Требования к маркировке и упаковке

4.6. Требования к хранению

5. ОБЩИЕ ХАРАКТЕРИСТИКИ ПРОГРАММНОГО ПРОДУКТА

80 Требования к ОП

Главные требования к основным разделам документа “Описания применения” (на выполнение этих требований будет обращаться повышенное внимание при сдаче ПО):

В п.1 (“НАЗНАЧЕНИЕ ПРОГРАММНОГО ПРОДУКТА”) дается более подробное, чем в ТЗ, назначение разрабатываемого программного продукта (ПО). Стиль должен быть простым и ориентированным на неподготовленного пользователя, как в рекламных объявлениях и рекламной информации. Документ может быть ориентирован на менеджеров и руководящих работников.

В п.2 (“ВОЗМОЖНОСТИ ПРОГРАММНОГО ПРОДУКТА”) приводятся все положительные свойства ПО, с пояснением, если нужно, условий функционирования и выгод его использования по сравнению с подобными программными продуктами. В нашем случае приводится описание классов на содержательном уровне и основных возможностей их применения. Не допускается использовать латинские названия методов, данных и перегруженных операций. Здесь, в нашем случае, приводиться диаграмма классов разработанного программного продукта.

В п.3 (“ОСНОВНЫЕ ХАРАКТЕРИСТИКИ ПРОГРАММНОГО ПРОДУКТА”) приводятся основные технические характеристики ПО. Эти характеристики можно оформить, для наглядности, в виде таблицы. Здесь отображаются: размеры используемой оперативной памяти, задействованные прерывания, ограничения на возможности создания объектов на основе системы классов (для нашего случая), объемы в ОП и т.д., все, что характеризует и отличает данный программный продукт. Можно давать сравнительные характеристики по сравнению с аналогичными программными продуктами.

В п.4 (“УСЛОВИЯ ПРИМЕНЕНИЯ ПРОГРАММНОГО ПРОДУКТА”) приводятся все ограничения и требования к применению ПО. В частности в п.4.2 может уточняться тип кодировки символов, типы форматы файлов для хранения информации и т.д., в зависимости от назначения и конструкции ПО. В этом разделе в обобщенном виде приводятся данные из ТЗ, связанные с условиями эксплуатации, хранением, транспортировкой ПО.

В п.5 (“ОБЩИЕ ХАРАКТЕРИСТИКИ ПРОГРАММНОГО ПРОДУКТА”) сведены общие и самые существенные характеристики ПО из предыдущих разделов. Эту информацию желательно тоже оформить в виде таблицы.

81 Техническое описание

82 Документ техническое описание (ТО) ПО и его назначение

Документ “Техническое описание” (ТО) программного продукта. Это фактически материалы технического проектирования ПП. В данном документе описывается конструкция изделия (модульный состав и связи). Здесь должно быть описано на техническом языке: как устроен ПП, как он сделан, из каких частей состоит, какие связи есть, какие внешние данные использует и т.д. Описываются все данные и методы классов. В данном документе даются все необходимые диаграммы для описания ПО: блок-схемы алгоритмов (можно ссылаться на листы), диаграммы классов, временные диаграммы, диаграммы объектов, диаграммы состояний и т.д. Документ предназначен для разработчиков или специалистов, которые будут сопровождать программный продукт, его изучать или модифицировать.

83 Стиль изложения ТО

Стиль изложения документа “Техническое описание” должен быть описательным, но основан на строгом техническом языке, принятом программистами и специалистами по разработке ПО (программистский жаргон здесь недопустим). Например, "файл имеет следующую структуру: …", "Процедура … имеет следующие входные и выходные параметры …", "класс имеет следующее назначение", "создаваемые объекты могут …" и т.д. Материал может быть (желательно) организован в виде наглядных таблиц, диаграмм, блок-схем и других формализованных описаний. В случае необходимости схемы и чертежи проекта могут быть вынесены на отдельные листы конструкторской документации, оформленные по ГОСТу. Из документа ТО, в этом случае, должны быть сделаны однозначные ссылки на содержание листов: например, “На Листе 2 представлена модульная структура программной системы …”.

84 Содержание ТО

Содержание документа ТО по пунктам приведено ниже. В образце документа ТО приведен документ ТО для варианта улиц и домов, описанного в общем пособии по курсу [3]. В шаблоне документа ТО (см. в конце данных методических указаний) даны методические указания к написанию и приспособлению документа применительно к конкретному варианту студента.

Содержание документа ТО:

1. ОБЩИЕ СВЕДЕНИЯ О ПРОГРАММНОМ ОБЕСПЕЧЕНИИ

2. МОДУЛЬНАЯ СТРУКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

3. ДИАГРАММА КЛАССОВ ПО

4. ОПИСАНИЕ МЕТОДОВ И ДАННЫХ КЛАССОВ ПО

5. ДАННЫЕ И ФАЙЛЫ ДАННЫХ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

6. ОСНОВНЫЕ АЛГОРИТМЫ МЕТОДОВ КЛАССОВ ПО

Характеристики

Список файлов книги