Реферат: Методические указания по курсовому проектированию для студентов направления 071900 Составители: А. Е. Докторов
МИНИСТЕРСТВО ОБРАЗОВАНИЯ РФ
УЛЬЯНОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ
РАЗРАБОТКА И ДОКУМЕНТИРОВАНИЕ ПРОГРАММ
МЕТОДИЧЕСКИЕ УКАЗАНИЯ ПО КУРСОВОМУ ПРОЕКТИРОВАНИЮ
ДЛЯ СТУДЕНТОВ НАПРАВЛЕНИЯ 071900
Составители: А.Е.Докторов,
Е.А.Докторова
Ульяновск 2000
УДК 681.3.08 (076)
ББК 32.973-01 я 7
Р 17
Рецензент доцент кафедры «Высшая математика», канд. техн. наук В.В. Селиванов
Одобрено секцией методических пособий научно-методического совета университета
Разработка и документирование программ: Методические указания по
Р 17 курсовому проектированию для студентов направления 071900 / Сост.: А.Е. Докторов, Е.А. Докторова. – Ульяновск: УлГТУ, 2000. – 38 с.
Составлены в соответствии с учебным планом направления 091700. Преследуют цель ориентировать студентов на содержание и порядок выполнения курсовой работы по программированию. Даются основные принципы и технология структурного программирования. Излагаются необходимые сведения по составу программной документации и требования к ней, соответствующие государственным стандартам ЕСПД. Работа подготовлена на кафедре ИВК.
УДК 681.3.08 (076)
ББК 32.973-01 я 7
© Оформление УлГТУ, 2000
© А.Е. Докторов,
Е.А. Докторова, 2000
Содержание
Содержание 3
ВВЕДЕНИЕ 3
1. ЦЕЛЬ КУРСОВОЙ РАБОТЫ 4
2. СУЩНОСТЬ СТРУКТУРНОГО ПРОГРАММИРОВАНИЯ 5
2.1. Проектирование «сверху вниз» 5
2.2. Модульное программирование 6
2.3. Структурное кодирование 8
2.4. Технология структурного программирования 8
3. ДОКУМЕНТИРОВАНИЕ И СТАДИИ РАЗРАБОТКИ ПРОГРАММЫ 10
3.1. Общие сведения о ЕСПД 13
3.2. Содержание программных документов 15
3.2.1. Техническое задание 15
3.2.2. Текст программы 16
3.2.3. Описание программы 16
3.2.4 Программа и методика испытаний 17
3.2.5. Описание применения 18
3.3. Стадии разработки программы 18
4. ПРИМЕР РАЗРАБОТКИ ПРОГРАММЫ 19
4.1. Постановка задачи 19
4.2. Предварительный анализ задачи 20
4.3. Проектирование программы 21
5. ОФОРМЛЕНИЕ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ 37
СПИСОК ЛИТЕРАТУРЫ 38
ВВЕДЕНИЕ
Для решения простейших задач программирования необходимо знать средства и возможности конкретного языка программирования. По мере усложнения задач знание свойств языка, оставаясь необходимым, уже не является фактором, определяющим успех проектирования программы. На первый план выдвигаются знание и умение конструировать логику вычислительного процесса в целом, а не отдельных его шагов. Определяющими здесь становятся вопросы методологии и технологии программирования.
Данные методические указания призваны восполнить этот пробел и помочь в выполнении курсовой работы, когда возникает необходимость решения достаточно сложной задачи программирования. В указаниях приводится краткое изложение особенностей структурного, модульного программирования. Значительная часть пособия посвящена ознакомлению студентов со стандартами, входящими в единую систему программной документации (ЕСПД), поскольку они регламентируют состав и содержание программных документов, оформляемых в процессе курсового проектирования. В указаниях также приводится иллюстрация процесса проектирования программы методом «сверху вниз» на примере решения относительно несложной задачи.
^ 1. ЦЕЛЬ КУРСОВОЙ РАБОТЫ
К моменту выполнения курсовой работы по программированию прослушан курс лекций по языку Турбо Паскаль, а также есть опыт выполнения лабораторных работ и прохождения учебной вычислительной практики. Задания лабораторных работ преследуют цель усвоения студентами отдельных средств языка программирования. Курсовая работа является следующим важным шагом в освоении методологии и технологии программирования, так как впервые ставит относительно сложную задачу создания программного продукта, для решения которой далеко недостаточно знать тонкости языка программирования.
В процессе проектирования программы практически осваиваются основные этапы этого процесса, а также правила документального оформления результатов каждого этапа в соответствии с требованиями ЕСПД, включающей в себя около 30 государственных стандартов.
С целью ознакомления с современными концепциями методологии и технологии программирования курсовая работа предполагает обязательное применение части из них и, прежде всего, реализации идей структурного программирования, которое не противоречит ни одному из современных методов борьбы со сложностью разработки программного обеспечения, будь то инструментальное программирование, объектно-ориентированное программирование или программирование с использованием прототипов.
^ 2. СУЩНОСТЬ СТРУКТУРНОГО ПРОГРАММИРОВАНИЯ
Сложность существующих программных систем превышает возможности человеческого интеллекта. Благодаря все новым и новым методологиям, технологиям и даже идеологиям создаются программные системы такой сложности, что все их задачи невозможно охватить одним разработчиком. Одной из таких технологий и является структурное программирование.
Структурное программирование предусматривает такую организацию проектирования программы и процесса кодирования, которая предотвращает большинство логических ошибок и обнаружение уже допущенных. Структурное программирование фокусирует усилия проектировщика на отработку логики программы, т.е. фактора программирования, наиболее подверженного ошибкам.
Структурное программирование включает три главные составляющие:
1. Проектирование «сверху вниз».
2. Модульное программирование.
Структурное кодирование.
^ 2.1. Проектирование «сверху вниз»
Проектирование программы «сверху вниз» это, прежде всего, правильная постановка задачи; разбиение этой задачи на подзадачи; разбиение этих подзадач на еще более мелкие подзадачи и т.д. Процесс такого поэтапного уточнения продолжается до тех пор, пока подзадачи не станут настолько простыми, что дальнейшее разбиение становится нецелесообразным. При этом каждой подзадаче будет соответствовать один модуль будущей программы.
Сначала необходимо уяснить постановку задачи и четко ее изложить. Приступая к проектированию, нужно на естественном языке описать то, что надлежит сделать. До этого момента к программированию приступать нельзя, поскольку такая попытка заведомо будет обречена на провал. Считается, что правильная постановка задачи это 90% ее решения.
Метод проектирования «сверху вниз» предусматривает сначала определение задачи в общих чертах, а затем постепенное уточнение структуры путем внесения более мелких деталей. На каждом шаге выявляются основные функции, которые нужно выполнить.
Описанный процесс на каждом этапе должен сопровождаться составлением спецификаций, в которых указывается, как программа или подпрограмма связаны с реальным миром или моделью реального мира. В результате получается письменный документ, который служит для справок и руководства к последующей работе.
Описание данных одна из составных частей задачи проектирования. Это описание должно включать тщательно подобранные примеры, демонстрирующие функции системы, и наиболее существенные варианты сочетаний значений данных.
Неизбежным этапом разработки является тестирование. В процессе описания каждого модуля должны быть описаны и его тестовые данные. Логическая проверка фрагментов программы уменьшает объем тестирования конечной программы. При использовании структурного программирования правильность программы обеспечивается уже самим методом программирования. Проектирование должно быть завершено до начала программирования.
Исправление ошибок, обнаруженных во время проектирования, обходится относительно недорого (переделать проект) по сравнению с обнаружением и исправлением ошибок на конечном этапе тестирования (перепрограммировать задачу).
Таким образом, до того как начать программирование, необходимо написать программу на естественном языке, разработать заранее тестовые данные, т.е. разработать проект, уделяя особое внимание исключению возможных ошибок.
^ 2.2. Модульное программирование
Модульное программирование это процесс разделения программы на логические части, называемые модулями, и последовательное программирование каждой части. Когда большая единая задача разделена на подзадачи, то значительно проще понять и прочесть программу.
Но важно не только преодоление сложности, но и заложенные в этом возможности написания правильных программ. Создавать монолитные программы размером до 1000 операторов, в которых отсутствуют ошибки, хотя и можно, но достаточно сложно. С помощью методов структурного модульного программирования можно программу из 1000 операторов записать в виде 20 модулей по 50 операторов в каждом, в виде последовательно выполняющихся частей программы.
При проектировании задачи «сверху вниз» она разбивается на подзадачи, каждой из которых соответствует модуль. При этом необходимо добиться, чтобы:
1) программный модуль не содержал ошибок и не зависел от контекста, в котором он будет использоваться;
2) из модулей можно было формировать большие программы без каких-либо предварительных знаний о внутренней работе модуля.
Все модули программы должны взаимодействовать, не оказывая никаких непредусмотренных действий друг на друга.
Примерное наилучшее ограничение в размере модуля не более 60 строк (допустимы исключения). Такая длина удобна для восприятия на странице или на дисплее.
Модули по возможности должны быть независимыми. Каждый модуль должен не зависеть: а) от источника входных данных; б) от места назначения выходных данных и в) от предыстории. В противном случае резко возрастает сложность системы. При соблюдении этих условий изменение в одной подпрограмме не повлияет на остальную часть программы. Воздействие изменения в одном модуле на другую часть программы получило название волнового эффекта. Этот эффект сводится к минимуму уменьшением связей между модулями.
Один из способов достижения этой цели это по возможности избегать использования глобальных переменных и делать модули небольшими. Минимизация связей между модулями (модульное сцепление) производится за счет усиления связей между элементами одного модуля (модульная прочность). Модули будут независимые, если любой модуль можно заменить новым, воспринимающим те же входные данные и выдающим такие же выходные, а на программе это не отразится, это означает, что модули независимые.
Фактор сложности включает три составляющие: функциональную, распределенную и связи. Функциональная сложность обусловлена тем, что один модуль выполняет слишком много функций. Распределенная сложность это сложность идентификации общей функции, распределенной между несколькими модулями, вследствие чего утрачивается возможность уменьшения сложности всей программы при модульном программировании. Сложность связи определяет сложность взаимодействия модулей при использовании общих данных.
Разбиение на модули должно происходить на стадии проектирования «сверху вниз». Для каждого модуля должны быть определены:
а) алгоритм решения задачи;
б) область допустимых входных значений;
в) область возможных выходных значений;
г) возможные побочные эффекты.
При разбиении программы на составные части необходимо придерживаться следующих рекомендаций:
каждый сегмент программы должен иметь один вход в начале и один выход в конце (если другие сегменты вызываются внутри какого-либо сегмента, то в них входят через начало, выходят через конец и возвращаются обратно в вызывающий сегмент);
главная процедура должна принимать все решения по управлению потоком данных для соответствующих обрабатывающих процедур;
каждый сегмент должен иметь как можно меньше ветвей вычислений (чем меньше размер модуля, тем меньше ветвей, которые надо тестировать); четкость программы в целом в большой степени зависит от четкости структуры каждого модуля.
Таким образом, каждая процедура является замкнутой. Управление передается от главной процедуры к вызываемой. Вызываемая процедура может в свою очередь вызвать другую процедуру, но в любом случае возврат всегда будет происходить в процедуру, являющуюся вызывающей для данной процедуры.
^ 2.3. Структурное кодирование
Структурное кодирование это метод написания хорошо структурированных программ, позволяющий получать программы, более удобные для тестирования, модификации и использования. Суть его состоит в том, что программы произвольного размера и сложности могут быть написаны с использованием ограниченного множества базисных структур.
Этот же прием положен в основу проектирования логических схем, где любая логическая функция может быть реализована из элементарных функций И, ИЛИ, НЕ. В булевой алгебре доказывается соответствующая теорема.
Аналогично структурное кодирование состоит в получении правильной программы из некоторых простых логических структур. Оно основано на строго доказанной теореме о структурировании, утверждающей, что любую правильную программу (с одним входом и одним выходом, без зацикливания и недостижимых команд) можно написать, используя лишь три логические структуры:
1) последовательности операторов;
2) выбора одного из двух операторов (IF THEN ELSE);
повторения оператора, пока выполняется некоторое условие.
Каждая структура имеет один вход и один выход. Можно получить программу любой сложности, применяя итерацию и вложение этих основных структур. При использовании только указанных структур отпадает необходимость в безусловных переходах и метках. Применение структурного программирования в значительной мере уменьшает сложность программ. Программу можно читать сверху вниз как печатный текст. Переходов, типичных для программ с оператором GOTO, здесь не будет. Важно заметить, что структурированные программы требуют более детального проектирования до программирования. Иначе невозможно остаться в пределах требуемой структуры, и мы вынуждены будем прибегать к переходам, чтобы реализовать непредусмотренные случаи. Цель структурированного программирования - обеспечить возможность чтения программы от начала до конца, следуя ее логике.
^ 2.4. Технология структурного программирования
Структурное программирование для каждого модуля предполагает следующий цикл разработки: составление спецификации, проектирование, кодирование, тестирование. Начинается оно с составления спецификации и проектирования главного модуля. Во время проектирования каждого модуля выявляются требования к подмодулям, после чего для каждого из подмодулей может быть составлена точная функциональная спецификация.
Функциональная спецификация является внутренним (не регламентированным соответствующим стандартом) документом разработки программы и может иметь произвольную форму. Функциональная спецификация представляет собой краткое описание каждого из модулей программы и может служить формальным заданием для его программирования. Она должна быть достаточно полной и по возможности унифицированной. В ней определяются способы управления модулем, описываются его входные и выходные данные, указываются ссылки на вызываемые и вызывающие модули. Спецификация также должна содержать описание внутренних (локальных) переменных и алгоритма.
Рекомендуемый вариант оформления функциональной спецификации может содержать разделы:
1) имя-заголовок (идентификатор модуля со списком формальных параметров);
2) назначение модуля;
3) неформальное описание (краткое изложение выполняемых функций);
4) ссылки (перечни вызывающих и вызываемых модулей);
5) алгоритм (с использованием псевдокодов или схем алгоритмов);
6) данные (описание формальных параметров, глобальных и локальных переменных с указанием структуры, типов и атрибутов размерности).
Преимущество программирования «сверху вниз», прежде всего, состоит в том, что спецификации каждого модуля фиксируются в процессе проектирования и не нуждаются, как правило, в последующих изменениях. В противоположность этому при программировании «снизу вверх», когда составление спецификации, проектирование, программирование и тестирование модулей начинается с самого нижнего уровня, всегда существует опасность того, что уже разработанные модули нижнего уровня придется изменять в результате неизбежно возникающих проблем или изменений при переходе к более высоким уровням иерархии.
При структурном программировании каждый модуль проверяется индивидуально, но не изолированно. Тестирование производится «сверху вниз». На каждом этапе функции модулей более низкого уровня моделируются при тестировании данного модуля по всем его логическим ветвям.
Благодаря принципу модульности главная программа должна быть короткой и вызывать модули более низкого уровня, которые можно моделировать, создавая так называемые подыгрывающие подпрограммы. Подыгрывающая программа очень короткая последовательность команд, которая используется как замена, пока не будет создана фактическая программа.
Подыгрывающие программы могут быть двух видов: фиктивные и замещающие модули. Фиктивные модули не выполняют никакой работы, а только возвращают управление вызывающему модулю. Замещающие модули используются для простой обработки до тех пор, пока не окажется возможным программировать более сложный модуль. Использование обращений к фиктивным подпрограммам позволяет производить компилирование, отладку и тестирование на более ранней стадии программирования. После выбора алгоритма вторым основным условием получения успешной программы является хороший проект. Всегда есть стремление быстрее начать программирование, однако без завершения проектирования это ни к чему хорошему не приводит. Кодирование это минимальная задача. Большинство решений следует принять до того, как начнется программирование, так как потом трудно будет изменить направление работы.
^ 3. ДОКУМЕНТИРОВАНИЕ И СТАДИИ РАЗРАБОТКИ ПРОГРАММЫ
Программа, как правило, разрабатывается не для того, кто является ее автором. Программу необходимо разрабатывать так, чтобы было понятно, как ее запускать, какой метод решения задачи в ней заложен, каковы требования к вводу (выводу) и т.д. Например, если в программной документации не указана размерность вводимых данных, то пользователь будет в большом затруднении при работе с такой программой.
При разработке программной документации нужно придерживаться государственных стандартов, объединенных в Единую систему программной документации (ЕСПД).
Согласно ГОСТ 19.10177 «Виды программ и программных документов» программы делятся на компоненты и комплексы. Компонент это программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса. Комплекс это программа, состоящая из двух или более компонентов и (или) комплексов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса.
Указанный стандарт определяет в качестве программных документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программы. Все документы делятся на две группы: программные (таблица1) и эксплуатационные (таблица 2).
Таблица 1 Вид программного документа Содержание программного документа Спецификация Состав программы и документации на нее Ведомость держателей подлинников Перечень предприятий, на которых хранят подлинники программных документов Текст программы Запись программы с необходимыми комментариями Описание программы Сведения о логической структуре и функционировании программы Программа и методика испытаний Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля Техническое задание Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний Пояснительная записка Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений
Таблица 2
Вид документа
Содержание документа
Ведомость эксплуатационных документов
Перечень эксплуатационных документов на программу
Формуляр
Основные характеристики программы, комплектность и сведения об эксплуатации программы
Описание применения
Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях на применение, минимальной конфигурации технических средств
Руководство системного программиста
Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения
Руководство программиста
Сведения для эксплуатации программы
Руководство оператора
Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы
Описание языка
Описание синтаксиса и семантики языка
Руководство по техническому обслуживанию
Сведения для применения тестовых и диагностических программ при обслуживании технических средств
Строгой регламентации перечня документов для каждой программы ГОСТ 19.101—77 не устанавливает, так как сложность программы и условия ее эксплуатации могут варьироваться в таких широких пределах, что невозможно точно указать, какая именно документация должна быть разработана в каждом конкретном случае. По этой причине ГОСТ 19.10177 допускает объединение отдельных видов эксплуатационных документов (за исключением ведомости эксплуатационных документов и формуляра).
Рекомендуемый перечень документов, разрабатываемых в процессе выполнения курсовой работы, должен включать:
Техническое задание.
Описание программы.
Текст программы.
Программу и методику испытаний (тестирования).
Описание применения.
Поскольку вся документация, разрабатываемая в процессе выполнения курсовой работы, должна отвечать требованиям ЕСПД, ниже приводится необходимая часть содержания стандартов.
^ 3.1. Общие сведения о ЕСПД
Согласно ГОСТ 19.001—93 «Единая система программной документации. Общие требования», ЕСПД это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ и программной документации.
Регламентация указанных процессов обеспечивает возможность:
унификации программных изделий для взаимного обмена программами и применения ранее разработанных программ в новых разработках;
снижения трудоемкости и повышения эффективности разработки, сопровождения, изготовления и эксплуатации программных изделий;
автоматизации изготовления и хранения программной документации.
Каждый документ должен иметь титульный лист и лист утверждения. Правила их заполнения регламентируются ГОСТ 19.10478 «Единая система программной документации. Основные надписи».
На титульный лист и лист утверждения выносятся следующие надписи: наименование министерства; наименование документа: обозначение документа; сведения о носителе данных, на котором представлен подлинник; общее количество листов утверждения; объем документа; сведения о разработчике; подпись нормоконтролера; отметка об учете и хранении; сведения об изменениях.
Лист утверждения оформляется на каждый программный документ на листах формата А4 (ГОСТ 2.301—68) независимо от вида документа, который может быть выполнен на любом носителе данных.
Обозначение листа утверждения состоит из обозначения документа, к которому он относится, и через дефис — шифра листа утверждения. Лист утверждения не входит в общее количество листов документа. Лист утверждения хранится на предприятии-держателе подлинника документа. Копии листа утверждения высылают заказчику и головному предприятию.
Программные документы подразделяются в зависимости от способа выполнения и характера применения на подлинники, дубликаты и копии (ГОСТ 2.102—68), предназначенные для разработки, сопровождения и эксплуатации программы.
Титульный лист заполняют по форме и правилам, установленным для листа утверждения.
Правила оформления последующих листов программных документов регламентируется ГОСТ 19.105—78 «Единая система программной документации. Общие требования к программной документации».
Согласно этому стандарту программный документ состоит из следующих условных частей:
титульной;
информационной;
основной;
регистрации изменений.
Титульная часть состоит из листа утверждения и титульного листа.
Информационная часть включает аннотацию и содержание (перечень разделов, подразделов с указанием номеров страниц). В аннотации приводятся сведения о назначении документа и краткое изложение его основной части.
Состав и структура основной части программного документа устанавливается другими стандартами ЕСПД (с частью из них мы познакомимся ниже).
Программные документы выполняют на листах формата А4 (ГОСТ 2.30668).
Материалы программного документа располагают в последовательности: титульная часть:
лист утверждения;
титульный лист (первый лист документа);
информационная часть:
аннотация;
лист содержания;
основная часть:
текст документа (с рисунками, таблицами и т. п.);
приложения;
перечень терминов;
перечень сокращений;
перечень рисунков;
перечень таблиц;
предметный указатель;
перечень ссылочных документов;
перечень символов и числовых коэффициентов;
часть регистрации изменений;
лист регистрации изменений.
Составляющие основной части, начиная от приложения и далее, выполняются при необходимости.
Рассматриваемый ГОСТ 19.106-78 устанавливает правила оформления, размещения в документе и нумерации текста, рисунков, таблиц и формул (из-за ограниченности объема методических указаний они здесь не приводятся).
Иллюстрированный материал, таблицы или текст вспомогательного характера допускается оформить в виде приложений. Приложения оформляют как продолжение данного документа или выпускают в виде отдельного документа. Каждое приложение должно начинаться с новой страницы с указанием в правом верхнем углу слова «ПРИЛОЖЕНИЕ» и иметь тематический заголовок, записываемый симметрично тексту прописными буквами. На приложения должны быть даны ссылки в основном документе. Все приложения должны быть перечислены в листе «Содержание».
^ 3.2. Содержание программных документов
В данном подразделе приводятся сведения о содержании лишь тех документов, оформление которых является обязательным при выполнении курсовой работы.
^ 3.2.1. Техническое задание
Порядок построения и оформления технического задания (ТЗ) на разработку программы или программного изделия устанавливается ГОСТ 19.201-78 «Единая система программной документации. Техническое задание. Требования к содержанию и оформлению».
На ТЗ оформляются лист утверждения и титульный лист. В документ не включаются информационная часть и лист регистрации изменений. Изменения и дополнения в Т3 на последующих стадиях разработки оформляют в виде дополнения к нему. ТЗ содержит следующие разделы:
введение (наименование, краткая характеристика области применения программы и объекта, в котором используют программу);
основание для разработки (документы), на базе которых ведется разработка; организация, утвердившая этот документ, и дата его утверждения; наименование и (или) условное обозначение темы разработки;
назначение разработки (функциональное и эксплуатационное назначение программы);
требования к программе или программному изделию (см. ниже);
требования к программной документации (состав и специальные требования к ней);
технико-экономические показатели (ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами);
стадии и этапы разработки (содержание работ на каждом этапе, сроки и исполнители);
порядок контроля и приемки (виды испытаний и общие требования к приемке работы).
В зависимости от особенностей программы допускается уточнять содержание разделов, вводить новые разделы или объединять некоторые из них.
Раздел «Требования к программе или программному изделию» должен содержать подразделы:
требования к функциональным характеристикам (составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т. д.);
требования к надежности;
условия эксплуатации (для выбранных типов носителей данных);
требования к составу и параметрам технических средств (их основные технические характеристики);
требования к информационной и программной совместимости (информационных структур на входе и на выходе, методов решения, исходных кодов, языков программирования и программных средств, используемых программ);
требования к маркировке и упаковке;
требования к транспортировке и хранению;
специальные требования.
^ 3.2.2. Текст программы
Требования к содержанию и оформлению текста программы устанавливаются ГОСТ 19.40178 «Единая система программной документации. Текст программы». Согласно этому стандарту составление информационной части (аннотации и содержания) является необязательным. Основная часть документа должна состоять из одного или нескольких разделов, которым даны наименования. Каждый из разделов реализуется одним из типов символической записи (например, запись на исходном языке). В символическую запись разделов рекомендуется включать комментарии.
^ 3.2.3. Описание программы
Требования к описанию программы устанавливает ГОСТ 19.402—78 «Единая система программной документации. Описание программы». Согласно этому стандарту составление информационной части (аннотации и содержания) не обязательно. Описание программы должно включать разделы:
общие сведения (обозначение и наименование программы - программное обеспечение, необходимое для функционирования программы, языки программирования, на которых она написана);
функциональное назначение (классы решаемых задач и/или назначение программы и сведения о функциональных ограничениях на применение);
описание логической структуры (алгоритм программы, используемые методы, структура программы с описанием функции составных частей и связи между ними, связи программы с другими программами);
используемые технические средства (для работы программы);
вызов и загрузка (способ вызова программы с соответствующего носителя данных, входные точки в программу, при необходимости сведения об использовании оперативной памяти, объем программы);
входные данные (характер и организация, формат, описание и способ кодирования входных данных);
выходные данные (то же, что и для входных данных).
Допускается содержание разделов иллюстрировать пояснительными примерами, таблицами, схемами, графиками.
^ 3.2.4 Программа и методика испытаний
Требования к программе и методике испытаний устанавливаются ГОСТ 19.301-79 «Единая система программной документации. Программа и методика испытаний». Согласно этому стандарту составление информационной части не обязательно. Документ должен содержать разделы:
объект испытаний (наименование, область применения и обозначение испытуемой программы);
цель испытания;
требования к программе (требования, подлежащие проверке во время испытаний и заданные в ТЗ на программу);
требования к программной документации (состав программной документации, предъявляемой на испытания, а также специальные требования, если они заданы в ТЗ на программу);
средства и порядок испытаний (технические и программные средства, используемые во время испытаний, а также порядок их проведения);
методы испытаний (описания проверок с указанием результатов проведения испытаний — перечней тестовых примеров, контрольных распечаток тестовых примеров и т. п.).
^ 3.2.5. Описание применения
Требования к описанию применения программы определены ГОСТ 19.502—78 «Единая система программной документации. Описание применения».
Составление информационной части является обязательным.
Текст документа должен включать разделы:
назначение программы (возможности программы, ее основные характеристики, ограничения, накладываемые на область применения программы);
условия применения (требования к необходимым для данной программы техническим средствам и другим программам, общие характеристики входной и выходной информации, а также требования и условия организационного, технического и технологического характера и т. п.);
описание задачи (определения задачи и методы ее решения);
входные и выходные данные.
^ 3.3. Стадии разработки программы
Стадии разработки программ и программной документации устанавливаются ГОСТ 19.102-77 «Единая система программной документации. Стадии разработки».
Стадии разработки должны быть следующие:
1. Техническое задание.
2. Эскизный проект.
3. Технический проект.
4. Рабочий проект.
5. Внедрение.
Этапы и содержание работ должны соответствовать приведенным в таблице в ГОСТ 19.102-77.
Примечания:
1. Допускается исключать вторую стадию разработки, а в технически обоснованных случаях – вторую и третью стадии. Необходимость проведения этих стадий указывается в техническом задании.
2. Допускается объединять, исключать этапы работ и (или) их содержание, а также вводить другие этапы работ по согласованию с заказчиком*.
^ 4. ПРИМЕР РАЗРАБОТКИ ПРОГРАММЫ
Процесс разработки программы, который будет приведен ниже, демонстрирует сущность программирования «сверху вниз». Предлагаемая задача не будет очень сложной, чтобы была возможность проследить логику разработки программы. Пример также не содержит документацию на программу.
^ 4.1. Постановка задачи
Задание. Разработать программу для автоматизации заполнения таблицы.
Форма таблицы задается в отдельном текстовом файле.
Например, это файл Tab_Form.txt, имеющий вид:
Price-list (Процессоры)
N
п/п
Фирма изготовитель
Частота,
МГц
Дополнительные сведения
Кол-во
Цена
Сумма
…………….
Перемещение по таблице клавишами стрелок.
Для изменения содержимого поля - Enter.
Выход из программы - Esc.
Количество строк в таблице – 15. Каждая из строк таблицы по указанной форме должна быть представлена в программе записью (типом record), содержащей поля следующих типов (по порядку в таблице):
а) целое число;
б) перечисляемый тип;
в) целое число;
г) строка;
д) целое число;
е) и ж) действительное число.
Здесь кроме формы таблицы приведена некоторая дополнительная информация, не меняющаяся во время работы программы (в приведенном пр
еще рефераты
Еще работы по разное
Реферат по разное
Методические указания для выполнения курсовых работ по дисциплине «экономическая теория» для студентов очного и заочного отделения Ижевск 2009
17 Сентября 2013
Реферат по разное
Методические указания к курсовому проектированию по дисциплине «основы безопасности труда»
17 Сентября 2013
Реферат по разное
Методические указания для студентов заочного отделения Новосибирск 2006
17 Сентября 2013
Реферат по разное
Методические указания и контрольные задания для студентов-заочников образовательного учреждения среднего профессионального образования по специальности 2913 Монтаж,
17 Сентября 2013