Документирование программного продукта

Автор работы: Пользователь скрыл имя, 20 Октября 2013 в 19:26, контрольная работа

Описание работы

В состав технической документации входят две стержневые части, которые мы будем называть соответственно руководством пользователя и справочником пользователя, или коротко: руководством и справочником (по аналогии с английскими словосочетаниями User's Guide и User's Reference). Они могут быть оформлены в виде отдельных документов (для крупных программных продуктов), а могут, напротив, существовать в интегрированном виде. Между ними даже может не быть четкой границы: единый текст способен совмещать в себе черты руководства и черты справочника. Руководство и справочник - это не столько части документации, сколько понятия, которые воплощают собой два подхода к описанию программного продукта.

Содержание работы

1. Документирование программного продукта. Структура документации. Стандартизация программной документации (ЕСПД). Централизованный фонд алгоритмов и программ (ЦФАП). Передача программных средств в ЦФАП. 3
2. Типовая структура программного комплекса. Элементарные базовые конструкции, используемые для построения программы. 11
3 Разработать техническое задание на создание ПО по теме: Автоматизация работы сотрудника отдела кадров. 15
4 Построить диаграмму вариантов использования в соответствии с требованиями, изложенными в ТЗ. 23
Литература 24

Файлы: 1 файл

Технология разработки ПО - Вариант 7 - МГВРК.doc

— 118.50 Кб (Скачать файл)

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

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

 

Группа

Сценарий

Пояснения

Вводные главы

"Быстрый старт"

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

Руководство  
пользователя

Ознакомительное  
чтение

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

Справочник  
пользователя

Получение справок по отдельным  элементам программного продукта

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

Специальные главы

Детальное знакомство с программным  продуктом

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


 

 

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

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

В целом: Сведения располагаются группами, "в несколько обходов". Такая группировка делает удобным переход от одного сценария к другому и поиск нужной группы сведений.

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

Стандартизация программной документации (ЕСПД).

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

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

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

ЕСПД устанавливает следующие  виды программной документации:

1. Спецификация. Состав программы  и документация на нее.

2. Ведомость держателей подлинников.  Перечень предприятий, на которых  хранят подлинники программных документов.

3. Текст программы. Запись программы  с необходимыми комментариями.

4. Описание программы. Сведения  о логической структуре и функционировании  программ.

5. Программа и методика испытаний.  Требования, подлежащие проверке  при испытании программы, а также порядок и методы контроля.

6. Техническое задание. Назначение  и область применения программы,  технические, технико-экономические  и специальные требования, предъявляемые  к программе, необходимые стадии  и сроки разработки, виды испытаний.

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

8. Эксплуатационные документы.  Сведения для обеспечения функционирования  и эксплуатации программы.

2. Типовая структура программного комплекса. Элементарные базовые конструкции, используемые для построения программы.

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

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

  • структурные карты Константайна 
    Предназначены для описания отношений между модулями

Базовыми строительными блоками  программируемой системы является модули. Все виды модулей во всех ЯП имеет ряд общих свойств:

  • модуль состоит из множества операторов ЯП
  • модуль имеет имя по которому к нему можно ссылаться как к единому фрагменту
  • модуль может принимать и/или передавать данные как параметры вызывающей последовательности или связывать данные через фиксированные ячейки или общие области.

Структурные карты Константайна являются моделью отношений в иерархии между программными модулями. Узлы структурных карт соответствуют модулям и областям данных. Потоки изображают межмодульные вызовы.

Фундаментальные элементы структурных  карт в соответствии со стандартами  IBM, ISO и ANSI:

  • любой модуль:

  • стрелка, касающаяся блока, всегда указывает ссылку к модулю целиком:

  • стрелка указывает ссылку к некоторому элементу внутри модуля:

  • связь по управлению:

  • связь по данным:

  • поток-вызов модуля:

Базовым элементом структурных  карт является модуль. Возможно использовать различные типы модулей:

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

  • A вызывает B как сопрограмму:

  • последовательный вызов:

  • параллельный вызов:

Для моделирования условных и циклических  вызовов применяются следующие  узлы:

  • циклические:

  • ветвление:

  • однократного выполнения:

Условный узел используется для  условного вызова модуля потомка.

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

Связи по данным и управлению между  модулями (передаваемые как параметры) раскрываются аннотированием потоков  вызовов.

  • связь по данным

  • связь по управлению

 

  • структурные карты Джексона.  
    Предназначены для описания внутренней структуры модулей.

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

 

 

 

 

 

 

 

3. Разработать техническое задание на создание ПО по теме: Автоматизация работы сотрудника отдела кадров.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Министерство образования Республики Беларусь

Учреждение образования

«Минский государственный высший радиотехнический колледж»

 

 

 

 

 

 

 

 

 

Автоматизация работы сотрудника отдела кадров

 

 

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Руководитель        Тарасова Т.М.

 

Разработчик          Орехов. А.В.

 

2013

 




Информация о работе Документирование программного продукта