Образец заполнения гост 19.402 78. Курс молодого бойца: Об оформлении программной документации (документация). Тестирование и отладка

19.11.2023 | Проблемы

Постановлением Государственного комитета СССР по стандартам от 18 декабря 1978 г. № 3350 срок введения установлен

с 01.01. 1980 г.

1. Настоящий стандарт устанавливает состав и требования к содержанию программного документа «Описание программы», определённого ГОСТ 19.101-77.

Стандарт полностью соответствует СТ СЭВ 2092-80.

2. Структуру и оформление документа устанавливают в соответствии с ГОСТ 19.105-78.

Составление информационной части (аннотации и содержания) является обязательным.

3. Описание программы должно содержать следующие разделы:

общие сведения;

функциональное назначение;

описание логической структуры;

используемые технические средства;

входные данные;

выходные данные.

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

4. В разделе «Общие сведения» должны быть указаны:

обозначение и наименование программы;

программное обеспечение, необходимое для функционирование программы;

языки программирования, на которых написана программа.

5. В разделе «Функциональное назначение» должны быть указаны классы решаемых задач и (или) назначение программы и сведения о функциональных ограничениях на применение.

6. В разделе «Описание логической структуры» должны быть указаны:

алгоритм программы;

используемые методы;

структура программы с описанием функций составных частей и связи между ними;

связи программы с другими программами.

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

3-6.(Измененная редакция, Изм. № 1).

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

способ вызова программы с соответствующего носителя данных;

входные точки в программу.

Допускается указывать адреса загрузки, сведения об использовании оперативной памяти, объем программы.

9. В разделе «Входные данные» должны быть указаны:

характер, организация и предварительная подготовка входных данных;

формат, описание и способ кодирования входных данных.

10. В разделе «Выходные данные» должны быть указаны:

характер и организация выходных данных;

формат, описание и способ кодирования выходных данных.

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

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

7-12.(Введены дополнительно, Изм. № 1).

* Переиздание (Ноябрь 1987 г.) с Изменением № 1, утвержденным в сентябре 1981 г (ИУС 11-81)

Постановлением Государственного комитета СССР по стандартам от 18декабря 1978 г. № 3350 срок введения установлен

с 01.01.1980 г.

1. Настоящий стандартустанавливает состав и требования к содержанию программного документа «Описаниепрограммы», определенного ГОСТ19.101-77 .

Стандарт полностьюсоответствует СТ СЭВ 2092-80.

2. Структуру и оформлениедокумента устанавливают в соответствии с ГОСТ19.105-78 .

Составление информационнойчасти (аннотации и содержания) является обязательным.

3. Описание программы должносодержать следующие разделы:

общие сведения;

функциональное назначение;

описание логическойструктуры;

входные данные;

выходные данные.

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

4. В разделе «Общиесведения» должны быть указаны:

обозначение и наименованиепрограммы;

программное обеспечение,необходимое для функционирования программы;

языки программирования, накоторых написана программа.

5. В разделе «Функциональноеназначение» должны быть указаны классы решаемых задач и (или) назначениепрограммы и сведения о функциональных ограничениях на применение.

6. В разделе «Описаниелогической структуры» должны быть указаны:

алгоритм программы;

используемые методы;

структура программы сописанием функций составных частей и связи между ними;

связи программы с другимипрограммами.

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

3-6. (Измененная редакция,Изм. № 1).

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

способ вызова программы ссоответствующего носителя данных;

входные точки в программу.

Допускается указывать адресазагрузки, сведения об использовании оперативной памяти, объем программы.

9. В разделе «Входныеданные» должны быть указаны:

характер, организация ипредварительная подготовка входных данных;

формат, описание и способкодирования входных данных.

10. В разделе «Выходныеданные» должны быть указаны:

характер и организациявыходных данных;

формат, описание и способкодирования выходных данных.

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

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

7-12. (Введеныдополнительно, Изм. № 1).

ГОСТ 19.402-78

Группа Т55

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

Единая система программной документации

ОПИСАНИЕ ПРОГРАММЫ

Unified system for program documentation. Program description.

МКС 35.080

Дата введения 1980-01-01

Постановлением Государственного комитета CCCР по стандартам от 18 декабря 1978 г. N 3350 дата введения установлена 01.01.80

ИЗДАНИЕ (январь 2010 г.) с Изменением N 1, утвержденным в сентябре 1981 г. (ИУС 11-81).

1. Настоящий стандарт устанавливает состав и требования к содержанию программного документа "Описание программы", определенного ГОСТ 19.101-77 .

Стандарт полностью соответствует СТ СЭВ 2092-80*.
________________
* Доступ к международным и зарубежным документам, упомянутым здесь, можно получить, перейдя по ссылке на сайт http://shop.cntd.ru . - Примечание изготовителя базы данных.

(Измененная редакция, Изм. N 1).

2. Структуру и оформление документа устанавливают в соответствии с ГОСТ 19.105-78 .

Составление информационной части (аннотации и содержания) является обязательным.

3. Описание программы должно содержать следующие разделы:

общие сведения;

функциональное назначение;

описание логической структуры;

используемые технические средства;

входные данные;

выходные данные.

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

4. В разделе "Общие сведения" должны быть указаны:

обозначение и наименование программы;

программное обеспечение, необходимое для функционирования программы;

языки программирования, на которых написана программа.

5. В разделе "Функциональное назначение" должны быть указаны классы решаемых задач и (или) назначение программы и сведения о функциональных ограничениях на применение.

6. В разделе "Описание логической структуры" должны быть указаны:

алгоритм программы;

используемые методы;

структура программы с описанием функций составных частей и связи между ними;

связи программы с другими программами.

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

3-6. (Измененная редакция, Изм. N 1).

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

способ вызова программы с соответствующего носителя данных;

входные точки в программу.

Допускается указывать адреса загрузки, сведения об использовании оперативной памяти, объем программы.

9. В разделе "Входные данные" должны быть указаны:

характер, организация и предварительная подготовка входных данных;

формат, описание и способ кодирования входных данных.

10. В разделе "Выходные данные" должны быть указаны:

характер и организация выходных данных;

формат, описание и способ кодирования выходных данных.

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

7-12. (Введены дополнительно, Изм. N 1).

Электронный текст документа
подготовлен АО "Кодекс" и сверен по:
официальное издание
Единая система программной документации:
Сборник национальных стандартов. -
М.: Стандартинформ, 2010

В.Э. Карпов

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

ТЕХНИЧЕСКОЕ ЗАДАНИЕ (ГОСТ 19.201-78)

1. Общие положения

СТАДИИ РАЗРАБОТКИ (ГОСТ 19.102-77)

ОПИСАНИЕ ПРОГРАММЫ (ГОСТ 19.402-78)

ТЕКСТ ПРОГРАММЫ (ГОСТ 19.401-78)

ПРОГРАММА И МЕТОДИКА ИСПЫТАНИЙ (ГОСТ 19.301-79)

ТРЕБОВАНИЯ К ПРОГРАММНЫМ ДОКУМЕНТАМ, ВЫПОЛНЕННЫМ ПЕЧАТНЫМ СПОСОБОМ (ГОСТ 19.106-78)

Стандартизация в области документирования программных средств

Как двигаться вперед

Подготовка документации на программные средства (ПС) в соответствии с имеющимися ГОСТами

2. Общая характеристика состояния

2.3. Государственные стандарты РФ (ГОСТ Р)

2.4. Международный стандарт ISO/IEC 12207: 1995-08-01

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

Во-первых, умение создавать программную документацию определяет профессиональный уровень программиста. Заказчик не будет вникать в тонкости и особенности даже самой замечательной программы. Заказчик будет сначала читать документацию. Большую роль играет в этом и психологический фактор. В частности, во всем мире ценилась (и ценится сейчас) былая советская школа программирования. Современные же отечественные программисты котироваться перестали. Класс не тот. Нынче программы уже не пишутся, а составляются (а это - "две большие разницы"). Так вот, созданный в "классическом" стиле пакет программной документации (далее - ПД) создаст у вашего заказчика или работодателя самое что ни на есть благоприятное впечатление. Тем более, если автор ПД будет избегать фраз вида "кликните на скроллбар…", "винт" и т.п. К сожалению, за подобной жаргонной трескотней обычно скрывается либо скудость мыслей, либо полная пустота (неизгладимое впечатление произвел на автора рассказ одного его знакомого о неком "геймере", который с кем-то там то ли "чатился", то ли "модераторством" занимался или что-то в этом роде.). Язык ПД - это своего рода бюрократический, весьма консервативный язык. Есть в нем своя особая прелесть. Согласитесь, что термины НЖМД, НГМД, ручной манипулятор типа "мышь" (или "колобок", как значилось в одном из старинных пакетов ПД) звучат совсем иначе, нежели соответствующие "винт", "флоп" и просто "мышь". Между прочим, дело уже дошло до того, что, говорят, появилась даже особая специальность - технический писатель, т.е. человек, умеющий создавать программную документацию.

Во-вторых, грамотно составленный (точнее, созданный) пакет ПД избавит вас от многих неприятностей. В частности, избавиться от назойливых вопросов и необоснованных претензий можно просто отослав пользователя к документации. Это касается прежде всего важнейшего документа - Технического задания. Об этом мы будем говорить ниже, а сейчас можно напомнить о многомиллионном иске к компании IBM. Этот иск предъявило одно крупное издательство, неудовлетворенное качеством ВТ и программного обеспечения. IBM суд выиграла. И выиграла только благодаря тому, что предъявила подписанное обеими сторонами Техническое задание. Было это давно, еще в 70-х гг., однако сути дела это не меняет.

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

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

ИПК "Издательство стандартов", Территориальный отдел распространения НТД (магазин "Стандарты"), 17961, Москва, ул. Донская, д. 8, тел. 236-50-34, 237-00-02, факс/тел. 236-34-48 (в части ГОСТ и ГОСТ Р).
ВНИИКИ Госстандарта России (читальный зал), 103001, Москва, Гранатный пер. д. 4, тел. 290-50-94 (в части международных, зарубежных стандартов и других НТД).

И никаких цитат и вторичных источников. ГОСТ - это закон. И тем более, никаких Интернетов (представьте себе суд, выносящий приговор, пользуясь распечаткой Уголовного Кодекса, скачанного с какого-нибудь сайта). Не верьте никому, кроме оригинала. Тем не менее, далее автору придется прибегать к цитированию ЕСПД, снимая при этом с себя всяческую ответственность.

Начнем с общих положений о Единой системе программной документации (которые тоже определены в соответствующем стандарте ГОСТ 19.001-77).

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

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

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

Вообще перечень документов ЕСПД очень обширен. В него, в частности, входят следующие ГОСТы:

ГОСТ 19.001-77 ЕСПД. Общие положения.
ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов (переиздан в ноябре 1987г с изм.).
ГОСТ 19.102-77 ЕСПД. Стадии разработки.
ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов.
ГОСТ 19.104-78 ЕСПД. Основные надписи.
ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам.
ГОСТ 19.106-78 ЕСПД. Требования к программным документам, выполненным печатным способом.
ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению.
ГОСТ 19.202-78 ЕСПД. Спецификация. Требования к содержанию и оформлению.
ГОСТ 19.301-79 ЕСПД. Программа и методика испытаний.
ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению.
ГОСТ 19.402-78 ЕСПД. Описание программы.
ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению.
ГОСТ 19.501-78 ЕСПД. Формуляр. Требования к содержанию и оформлению.
ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению.
ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению.
ГОСТ 19.504-79 ЕСПД. Руководство программиста.
ГОСТ 19.505-79 ЕСПД. Руководство оператора.
ГОСТ 19.506-79 ЕСПД. Описание языка.
ГОСТ 19.508-79 ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению.
ГОСТ 19.604-78 ЕСПД. Правила внесения изменений в программные документы, выполняемые печатным способом.
ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.
ГОСТ 19.781-90. Обеспечение систем обработки информации программное.

Как видно, основная часть комплекса ЕСПД была разработана в 70-е и 80-е годы. Частично эти стандартны морально устарели, к тому же они не лишены некоторых недостатков. Во-первых, в них не отражены некоторые современные тенденции оформления программ и программной документации, во-вторых, в этих стандартах наличествует многократное дублирование фрагментов программной документации. Тем не менее, за неимением лучшего ориентироваться приходится именно на них.

Итак, стандарты ЕСПД упорядочивают процесс документирования программных систем. Однако, во-первых, предусмотренный стандартами ЕСПД состав программных документов вовсе не такой "жесткий", как может показаться: стандарты позволяют вносить в комплект документации на программной системы (ПС) дополнительные виды, а, во-вторых, исходя из требований заказчика, допустимы некоторые изменения как в структуре, так и в содержании установленных видов ПД. Более того, можно отметить, что стандарты ЕСПД (а это относится и ко всем другим стандартам в области ПС - ГОСТ 34, Международному стандарту ISO/IEC, и др.) носят рекомендательный характер. Дело в том, что в соответствии с Законом РФ "О стандартизации" эти стандарты становятся обязательными на контрактной основе - т.е. при ссылке на них в договоре на разработку (поставку) ПС.

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

И еще. Описывая свой продукт, разработчик зачастую путает понятия компонента и комплекса. Это - разные виды программ. Компонент определяется как "программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса" , а комплекс - это "программа, состоящая из двух или более компонентов и (или) комплексов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса" .

Согласно ГОСТу, настоящий стандарт (переизданный в ноябре 1987 г.) устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.

Надо быть предельно внимательным и осторожным, создавая его, т.к. зачастую умело (и грамотно) составленное ТЗ определяет успех всей работы. Именно ТЗ согласовывается с Заказчиком, который обычно стремится внести как можно больше противоречивых и завышенных требований. Задача же Исполнителя - наоборот, облегчить себе жизнь. Но после того, как подписи с обеих сторон поставлены, переигрывать что-либо поздно.

Техническое задание оформляют на листах формата А4 и/или А3, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.

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

Техническое задание должно содержать следующие разделы:

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

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

В разделе Наименование и область применения указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

В разделе Основание для разработки должны быть указаны:

документ (документы), на основании которых ведется разработка;
организация, утвердившая этот документ, и дата его утверждения;
наименование и (или) условное обозначение темы разработки.

Применительно к специфике учебного процесса основанием может служить задание на курсовое проектирование, приказ по институту от __.__. за N ___., договор __.__. за N ___. , и т.п.

В разделе Назначение разработки должно быть указано функциональное и эксплуатационное назначение программы или программного изделия. Ограничиться здесь можно одной-двумя фразами. Главное - четко определить, для чего нужна эта программа.

Например: Программа представляет собой ядро автоматизированного рабочего места (АРМ) разработчика непрерывных линейных систем автоматического управления (САУ), позволяющее пользователю решать задачи анализа простых моделей.

Раздел Технические требования к программе или программному изделию должен содержать следующие подразделы:

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

Иными словами, здесь начинается конкретика. Описывается то, что должна делать программа и как она должна выглядеть.

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

Например: Программа должна позволять … вычислять … строить… создавать …

Исходные данные: текстовый файл с заданной …

Выходные данные: графическая и текстовая информация - результаты анализа системы…; текстовые файлы - отчеты о … диагностика состояния системы и сообщения о всех возникших ошибках.

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

Здесь "выгадать" что-то сложно. В лучшем случае может пройти вариант, при котором ваша программа работает только с абсолютно корректными данными. Обычно Заказчик на это не идет, но попробовать можно.

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

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

С этим пунктом сложностей обычно не возникает. К сожалению, пункт о профессиональности пользователя Заказчиком подразумевается обязательно. Это, конечно, лишний повод придраться к вашей программе. Впрочем, здесь можно ограничиться фразами вида "Условия эксплуатации программы совпадают с условиями эксплуатации ПЭВМ IBM PC и совместимых с ними ПК", "Программа должная быть рассчитана на непрофессионального пользователя." и т.п.

Требования к составу и параметрам технических средств. Указывают необходимый состав технических средств с указанием их технических характеристик.

Здесь главное - ничего не забыть и все предусмотреть, с одной стороны (а то подсунут какой-нибудь IBM PC/XT с монохромным дисплеем и без мыши), а с другой - не переборщить с повышенными требованиями, иначе Заказчик найдет более покладистого Исполнителя.

Например: Необходимо наличие IBM PC - совместимого ПК с графическим адаптером EGA (VGA). Необходимое дисковое пространство - не менее 600 Кб, объем свободной оперативной памяти - не менее 400 Кб. Желательно наличие драйвера EMS и манипулятора типа "мышь".

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

Например: Программа должна работать автономно под управлением ОС MS DOS версии не ниже 3.3. Базовый язык программирования - Turbo Pascal 6.0.

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

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

Например: Специальных требований к временным характеристикам программы не предъявляется. Специальных требований к емкостным характеристикам программы не предъявляется.

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

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

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

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

Здесь описываются стандартные этапы. Главное - грамотно определиться со сроками. По возможности, старайтесь равномерно распределить этапы по срокам (и суммам). Помните, что не все проекты доживают до последней стадии. А отчеты должны быть по каждому этапу. Помните также, что больше всего времени займет рабочий проект. Если вы не успеете сделать в срок документацию, то Заказчик имеет полное право вообще не принять работу со всеми вытекающими последствиями.

Основными и непременными стадиями и этапами являются само техническое задание, эскизный проект, технический и рабочий проекты.

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

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

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

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

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

технико-экономические показатели;
структура программы;
формат представления входных данных программы;
общая схема алгоритма (2 листа);
основные вычислительные алгоритмы;
пример работы программы.

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

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

В Приложениях к техническому заданию, при необходимости, приводят:

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

другие источники разработки.

Этот стандарт устанавливает стадии разработки программ, программной документации, а также этапы и содержание работ:

Стадии разработки	Этапы работ
Техническое задание	Обоснование необходимости разработки программы	Постановка задачи. Сбор исходных материалов. Выбор и обоснование критериев эффективности и качества разрабатываемой программы. Обоснование необходимости проведения научно-исследовательских работ.
	Научно-исследователь-ские работы	Определение структуры входных и выходных данных. Предварительный выбор методов решения задач. Обоснование целесообразности применения ранее разработанных программ. Определение требований к техническим средствам. Обоснование принципиальной возможности решения поставленной задачи.
	Разработка и утверждение технического задания	Определение требований к программе. Разработка технико-экономического обоснования разработки программы. Определение стадий, этапов и сроков разработки программы и документации на нее. Выбор языков программирования. Определение необходимости проведения научно-исследовательских работ на последующих стадиях. Согласование и утверждение технического задания.
Эскизный проект	Разработка эскизного проекта	Предварительная разработка структуры входных и выходных данных. Уточнение методов решения задачи. Разработка общего описания алгоритма решения задачи. Разработка технико-экономического обоснования.
Эскизный проект	Утверждение эскизного проекта	Согласование и утверждение эскизного проекта
Технический проект	Разработка технического проекта	Уточнение структуры входных и выходных данных. Разработка алгоритма решения задачи. Определение формы представления входных и выходных данных. Определение семантики и синтаксиса языка. Разработка структуры программы. Окончательное определение конфигурации технических средств.
Технический проект	Утверждение технического проекта	Разработка плана мероприятий по разработке и внедрению программ. Разработка пояснительной записки. Согласование и утверждение технического проекта.
Рабочий проект	Разработка программы	Программирование и отладка программы
	Разработка программной документации	Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77.
	Испытания программы	Разработка, согласование и утверждение программы и методики испытаний. Проведение предварительных государственных, межведомственных, приемо-сдаточных и других видов испытаний. Корректировка программы и программной документации по результатам испытаний.
Внедрение	Подготовка и передача программы	Подготовка и передача программы и программной документации для сопровождения и (или) изготовления. Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление. Передача программы в фонд алгоритмов и программ.

Примечания:

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

Этот стандарт ориентирован на документирование результирующего продукта разработки.

Строго говоря, существуют два разных документа, имеющих, правда, много общего. Это ОБЩЕЕ ОПИСАНИЕ (ГОСТ 19.502-78) и ОПИСАНИЕ ПРОГРАММЫ (ГОСТ 19.402-78). Однако, в силу того, что реально создать качественно и тот, и другой, не прибегая к почти полному дублированию, выдирая куски, весьма сложно, было бы достаточно реализовать один, более общий, "гибридный" документ. Назовем его "Описанием программы".

На самом деле "Описание программы" в своей содержательной части может дополняться разделами и пунктами, взятыми и из стандартов для других описательных документов и руководств: ГОСТ 19.404-79 ЕСПД. Пояснительная записка, ГОСТ 19.503-79 ЕСПД. Руководство системного программиста, ГОСТ 19.504-79 ЕСПД. Руководство программиста, ГОСТ 19.505-79 ЕСПД. Руководство оператора и т.п. В частности, из Пояснительной записки можно взять схему алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений.

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

Основная часть документа должна состоять из вводной части и следующих разделов:

функциональное назначение;
описание логики.
условия применения;
состав и функции.

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

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

Например: Программа "Автоматизированное рабочее место разработчика САУ" предназначена для … реализована на …. Программа поддерживает …

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

Например: Программа предназначена для решения задач … Программа представляет собой ядро автоматизированного рабочего места …

Пользователь имеет возможность …, осуществить …, запустить …, проанализировать …, получить результаты анализа и обработки …, построить … и т.п.

В разделе "Описание логики " указывают:

описание структуры программы и ее основных частей

(например: В состав программы входит следующее:

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

описание функций составных частей и связей между ними;

Например: Программа состоит из шести модулей: интерфейсный модуль; модуль определения …; модуль расчета …; модуль …и т.п..

Интерфейсный модуль построен на двух типах диалогов: диалог "вопрос - ответ" и диалог типа "меню". Интерфейсный модуль управляет …

Модуль определения … Он является …

Модуль расчета …и т.д.

сведения о языке программирования;

Например: Программа написана на языке …с использованием компилятора …

описание входных и выходных данных для каждой из составных частей;

Например: ВХОДНЫЕ ДАННЫЕ. Входными данными для программы является текстовый файл, описывающий расширенную матрицу инциденций графа исследуемой системы.

ВЫХОДНЫЕ ДАННЫЕ. Выходными данными являются:

выводимая на экран графическая и текстовая информация (результаты анализа системы);
файлы в одном из графических форматов - копии изображения построенных характеристик (АЧХ,ФЧХ и т.д.);
текстовые файлы - отчеты о проведенных исследованиях;
диагностика состояния системы и сообщения о всех возникших ошибках.

описание логики составных частей (при необходимости следует составлять описание схем программ).

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

В разделе Состав и функции указывают описание состава и функции программ, применяемых методов решения задач.

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

Например: Программа эксплуатируется на персональном компьютере (ПК) типа IBM PC/AT. Для работы в диалоговом режиме используется экран дисплея, клавиатура и манипулятор типа "мышь". Для поддержки графического режима необходим адаптер EGA (VGA). Входные данные хранятся на флоппи- и/или жестком дисках. Программа работает под управлением ОС …

В приложение к описанию могут быть включены справочные материалы (иллюстрации, таблицы, графики, примеры и т.п.)

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

Вызова и загрузки системы

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

По-прежнему обязательным является составление информационной части - аннотации и содержания.

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

Текст каждого программного файла начинается с "шапки", в которой указывается:

наименование программы,
автор,
дата создания программы,
номер версии,
дата последней модификации.

Обязательными являются комментарии, а также строгое соблюдение правил отступа. Помните, оправдать можно даже неумение создавать программную документацию. А некрасивый текст программы - никогда. Ссылки на то, что этот текст понятен самому автору всерьез не воспринимаются. Тексты программ должно быть не стыдно давать читать другим людям.

Ниже приведен пример подобного хорошо читаемого текста программы (взят с сайта Николая Гехта, e-mail:[email protected], http://users.omskreg.ru/~geht)

/* Исходные тексты Windows"98

Source Code to Windows 98 */ #include "win31.h" #include "win95.h" #include "evenmore.h" #include "oldstuff.h" #include "billrulz.h" #include "monopoly.h" #define INSTALL = HARD char make_prog_look_big; void main() { while(!CRASHED) { display_copyright_message(); display_bill_rules_message(); do_nothing_loop(); if(first_time_installation) { make_50_megabyte_swapfile(); do_nothing_loop(); totally_screw_up_HPFS_file_system(); search_and_destroy_the_rest_of_OS/2(); disable_Netscape(); disable_RealPlayer(); disable_Corel_Products(); hang_system(); } write_something(anything); display_copyright_message(); do_nothing_loop(); do_some_stuff(); if(still_not_crashed) { display_copyright_message(); do_nothing_loop(); basically_run_windows_3.1(); do_nothing_loop(); do_nothing_loop(); } } if(detect_cache()) disable_cache(); if(fast_cpu()) { set_wait_states(lots); set_mouse(speed, very_slow); set_mouse(action, jumpy); set_mouse(reaction, sometimes); } /* printf("Welcome to Windows 3.11"); */ /* printf("Welcome to Windows 95"); */ printf("Welcome to Windows 98"); if(system_ok()) crash(to_dos_prompt) else system_memory = open("a:\swp0001.swp", O_CREATE); while(something) { sleep(5); get_user_input(); sleep(5); act_on_user_input(); sleep(5); } create_general_protection_fault();

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

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

Составные части этого документа проще и нагляднее описывать сразу в виде примеров.

Объект испытаний

Пример: Объектом испытаний является программа …, предназначенная для …

Цель испытаний

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

Требования к программе

Пример: Функционирование программы не должно приводить к сбою (фатальному нарушению работы системы). Организация диалога должна предусматривать защиту от ввода некорректных данных. Программа должна выдавать диагностику состояния системы и сообщения о любых возникших ошибках … и т.п.

Требования к программной документации

Пример: Состав программной документации, предъявляемой на испытании:

описание программы (ГОСТ 19.402-78);
программа и методика испытаний (ГОСТ 19.301-79);
текст программы (ГОСТ 19.401-78).

Средства и порядок испытаний

Пример: Программа работает в соответствии с условиями эксплуатации ОС MS DOS (версия не ниже 3.0) на ПК типа IBM PC/AT, а также на совместимых с ним. Для работы необходим также адаптер EGA (VGA).

Порядок проведения испытаний:

Запуск программы осуществляется ….
Выбирается …
Нажимается …
Последовательно выбираются …

Тестовые примеры

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

И, наконец, рассмотрим последний стандарт ЕСПД, который называется

Этот стандарт устанавливает правила выполнения программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения и предусмотренных стандартами ЕСПД.

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

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

Повреждение листов документов, помарки и следы не полностью удаленного текста (графики) не допускаются.

Программные документы оформляют на листах формата А4. Кроме того:

допустимо оформление на листах формата А3;
при машинном способе выполнения документа допускаются отклонения размеров листов, соответствующих форматам А4 и А3, определяемые возможностями применяемых технических средств; на листах форматов А4 и А3, предусматриваемых выходными характеристиками устройств вывода данных, при изготовлении документа машинным способом;
при изготовлении документа типографским способом возможно использование листов типографических форматов.

Расположение материалов программного документа осуществляется в следующей последовательности:

титульная часть:

лист утверждения (не входит в общее количество листов документа);
титульный лист (первый лист документа);

информационная часть:

аннотация;
лист содержания;

основная часть:

текст документа (с рисунками, таблицами и т.п.);
перечень терминов и их определений;
перечень сокращений;
приложения;
предметный указатель;
перечень ссылочных документов;

часть регистрации изменений:

лист регистрации изменений.

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

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

Аннотацию размещают на отдельной странице (страницах), снабжают заголовком "АННОТАЦИЯ", нумеруют и включают в содержание документа.

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

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

Разделы, подразделы, пункты и подпункты следует нумеровать арабскими цифрами с точкой. Разделы должны иметь порядковый номер (1, 2 и т.д.)

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

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

Если сноска относится к отдельному слову, знак сноски помещается непосредственно возле этого слова, если же к предложению целом, то в конце предложения. Текст сноски располагают в конце страницы и отделяют от основного текста линией длиной 3 см, проведенной в левой части страницы.

Иллюстрации. Иллюстрации могут быть расположены в тексте документа и (или) в приложениях. Иллюстрации, если их в данном документе более одной, нумеруют арабскими цифрами в пределах всего документа.

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

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

Ссылки в тексте на порядковый номер формулы дают в скобках, например: "в формуле (3)". При делении документа на части номер части ставится перед порядковым номером формулы и отделяется от последней точкой, например: "в формуле (1.4)".

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

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

Допускается указывать только обозначение документа и (или) разделов без указания их наименований. Ссылки на отдельные подразделы, пункты и иллюстрации другого документа не допускаются. Допускаются ссылки внутри документа на пункты, иллюстрации и отдельные подразделы.

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

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

сокращений, установленных в ГОСТ 2.316-68, и общепринятых в русском языке;
сокращений, применяемых для обозначения программ, их частей и режимов работы, в языках управления заданиями, в средствах настройки программы и т.п., обозначаемых буквами латинского алфавита.

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

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

Приложение 1, Приложение 2 и т.д.

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

Общие сведения

Обозначение и наименование программы

Программабазы данных« Расчёт платежей за коммунальные услуги ТСЖ».

Программное обеспечение, необходимое для функционирования программы

ПакетDelphi7полностьюподдерживаетновейшие иуже существующие Web-сервисы.

Программа Delphi 7 позволяет создавать самые различные программы: от простейших однооконных приложений до программ управления распределенными базами. В состав пакета включены разнообразные утилиты, обеспечивающие работу с базами данных, XML-документами, создание справочной системы, решение других задач. Отличительной особенностью седьмой версии является поддержка технологии.NET.

Языки программирования, на которых написана программа

Программа написана на языке Object Pascal и предназначена для обработки компилятором.

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

Информационная система «Расчет платежей за коммунальные услуги ТСЖ-99» предназначена для автоматизации рабочего места управляющего ТСЖ, ведения расчета оплаты за коммунальные услуги для квартиросъёмщиков.

Описание логической структуры

Логическая структураприведена в приложении А.

Используемые методы

Для подключения базы данных к Delphi используются технология ADOConnection.

ADO – ActiveXDataObjects.Технология MicrosoftActive X DataObjects обеспечивает универсальный доступ к источникам данных, из приложений БД. Такую возможность предоставляют функции набора интерфейсов, созданные на основе общей модели объектов СОМ (Component Object Model) и описанные в спецификации OLE DB. Провайдеры ADO обеспечивают соединение приложения, использующего данные через ADO, с источником данных (сервером SQL, локальной СУБД, файловой системой и т. д.). Для каждого типа хранилища данных должен существовать провайдер ADO. Microsoft Jet OLE DB Provider обеспечивает соединение с данными СУБД Access. Использование ADO позволяет отказаться от установки BDE и поставки дополнительных библиотек на ПК конечного пользователя разрабатываемого приложения БД.

Структура программы

Структура программных файлов

При разработке и сохранения проекта в среде программирования Delphi файлы проекта, формы и другие файлы сохраняются в общей папке:

*.ddp – файл для разработки Delphi;

*.dfm- файл с описанием строения формы;

*.pas- исходный код модуля;

*.dcu- скомпилированный модуль Delphi;

*.dof - текущие параметры проекта;

*.cfg - файлы конфигурации проекта

*.dpr- файл проекта;

*.ехе - исполняемый файл;

*.res – результирующий файл, файл ресурсов;

*.gui – файл данных;

*.chm – файл для справки;

*.mdb – файл базы данных Access.

Структура программных модулей

Unit – имя модуля (файла).

Interface – используется для внешних определений модуля.

Uses- подключение стандартных библиотек и модулей.

{Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs}

Type – описание класса TForm с его полями и методами.

private – описание данных (полей) и подпрограмм (методы) класса, которые являются частными (внутренними) для этого класса.

{Privatedeclarations}

Public - переменные, открытые для всех модулей.

{Publicdeclarations}

Var – описание глобальных переменных.

Implementation – начинает раздел исполняемого кода в модуле.

Function – пользовательскиефункции.

{$R *.DFM} – подключение файла формы.

procedure<имя> (Sender: TObject);

Var – описание локальных переменных.

Блок активированных процедур

Используемые технические средства

В состав технических средств компьютер включает в себя:

Процессор:IntelCore i54460, частота процессора 3.2 ГГц,количество ядер процессора – 4, чипсет материнской платы - Intel H81;

Оперативная память: DIMM, DDR34096 Мб 1600 МГц, максимальный объем оперативной памяти - 16 Гб;

Жесткий диск:500 Гб, 7200 об/мин, SATA III;

Мышь, монитор, клавиатура.

Входные данные

Входными данными являются:

Data Module DFM: ADO Connection BD –подключение базы данных к Delphi; ADO Table Sob, ADO Table Voda, ADO Table Giljo, ADO Table Otopl, ADO Table Svet, ADO Table Obslug, ADO Table Quit, ADO Table Requisites – таблица из БД;

Form Avtorisation: Combo Box User Name – выборпользователей; Edit Password – вводпароля;

Form Requisites: DB Edit Adr–ввод юридического адреса, DB Edit Naim TSG –вводнаименованияТСЖ, DB Edit Tel –вводномерателефона, DB Edit INN- вводИНН,DB Edit BIK- вводБИК, DB Edit RS- вводрасчётногосчёта, DB Edit KS- вводкорреспондентскогосчёта;

Form Table Sobstvennikov: Edit Poisk–ввод поиска по ФИО квартиросъёмщика, DB Edit FIO –ввод ФИО квартиросъёмщика, DB Edit LS –ввод лицевого счёта, DB Edit kolvo- ввод количества проживающих, DB Edit PL- ввод общей площади, DB Edit Adr–ввод адреса;

Form Table Tarifes: DB Edit Naimvoda–вводнаименованиятарифанаводу, DB Edit edvoda–ввод единицы измерения для воды, DB Edit voda- вводтарифанаводу, DB Edit Naimgiljo–ввод наименования тарифа на жильё, DB Edit ed giljo–вводединицыизмерениядляжилья, DB Edit giljo–вводтарифанажильё, DB Edit Naim otopl–ввод наименования тарифа на отопление, DB Edit ed otopl–вводединицыизмерениядляотопления, DB Edit otopl–вводтарифанаотопление, DB Edit Naimsvet–вводнаименованиятарифанасвет, DB Edit edsvet–вводединицыизмерениядлясвета, DB Edit svet–вводтарифанасвет, DB Edit Naimobslug–вводнаименованиятарифанатех. обслуживание, DB Edit edobslug–вводединицыизмерениядлятех. обслуживания, DB Edit obslug–вводтарифанатех. обслуживание;

Form Table Kvitanzia: DB Edit NP voda - вводначальногопоказаниясчётчиканаводу, DB Edit KP voda–вводконечногопоказаниясчётчиканаводу, DB Edit kolvovoda- вводколичествапосчётчикунаводу, DB Edit NP giljo–вводначальногопоказаниясчётчиканажильё, DB Edit KP giljo–вводконечногопоказаниясчётчиканажильё, DB Edit kolvogiljo–вводколичествапосчётчикужилья, DB Edit NP otopl–вводначальногопоказаниясчётчиканаотопление, DB Edit KP otopl–вводконечногопоказаниясчётчиканаотопление, DB Edit kolvootopl–вводколичествапосчётчикунаотопление, DB Edit NP svet–вводначальногопоказаниясчётчиканасвет, DB Edit KP svet–вводконечногопоказаниясчётчиканасвет, DB Edit kolvosvet–вводколичествапосчётчикунасвет, DB Edit NP obslug–вводначальногопоказаниясчётчиканатехобслуживание, DB Edit KP obslug–вводконечногопоказаниясчётчиканатехобслуживание, DB Edit kolvoobslug–вводколичествапосчётчикунатехобслуживание, DB Lookup Combo box Number- выборличногономера,DB Lookup Combo box LS –выборлицевогосчёта, DB Lookup Combo boxadr - выборадреса, DB Lookup Combo box kolvo–выборколичествапроживающих, DB Lookup Combo box pl –выборплощадиквартир, DB Lookup Combo box NaimVoda–выборнаименованиятарифанаводу, DB Lookup Combo box NaimGiljo–выборнаименованиятарифанажильё, DB Lookup Combo box NaimOtopl–выборнаименованиятарифанаотопление, DB Lookup Combo box NaimSvet–выборнаименованиятарифанасвет, DB Lookup Combo box NaimObslug–выборнаименованиятарифанатехобслуживание, DB Lookup Combo box Voda–выбортарифанаводу, DB Lookup Combo box Giljo–выбортарифанажильё, DB Lookup Combo box Otopl–выбортарифанаотопление, DB Lookup Combo box Svet–выбортарифанасвет, DB Lookup Combo box Obslug–выбортарифанатехобслуживание, DB Lookup Combo box Ed Voda–выборединицыизмерениянаводу, DB Lookup Combo box Ed Giljo–выборединицыизмерениянажильё, DB Lookup Combo box Ed Otopl–выборединицыизмерениянаотопление, DB Lookup Combo box Ed Svet–выборединицыизмерениянасвет, DB Lookup Combo box Ed Obslug–выборединицыизмерениянатехобслуживание, DB Lookup Combo box FIO –выборФИОквартиросъёмщика;

Form Export: DB Lookup Combo box Number- выборличногономера, DB Lookup Combo box LS –выборлицевогосчёта, DB Lookup Combo box adr–выборадреса, DB Lookup Combo box kolvo–выборколичествапроживающих, DB Lookup Combo box pl –выборплощадиквартир, DB Lookup Combo box FIO –выборФИОквартиросъёмщика, DB Date Time Picker Word –вводдатыраспечатаннойквитанции.

Выходные данные

Выходными данными являются:

FormTarifes: DBGridVoda - вывод информации о тарифах на воду в таблице, DBGridGiljo - вывод информации о тарифах на жильё в таблице, DBGridotopl - вывод информации о тарифах на отопление в таблице, DBGridsvet - вывод информации о тарифах на свет в таблице, DBGridobslug - вывод информации о тарифах на тех обслуги в таблице;

FormKvitanzia: DBGridQuit - вывод информации о квитанции в таблице;

FormSobstvenniki: DBGridSob - вывод информации о собственниках в таблице.

Описание программы составлено в соответствии с ГОСТ 19.402-78. ЕСПД. Требования к содержанию и оформлению.

ПРОЦЕСС РАЗРАБОТКИ

Для разработки ИС «Расчёт платежей за коммунальные услуги ТСЖ» воспользуемся инструментальной средой Delphi7, с её взаимодействием со средой MSAccess, через компоненты ADO.Основное окно программы содержит следующие части:

Системное меню (1);

Панель инструментов(2);

Окно для всех таблиц (3);

Палитра компонентов (4);

Модуль (6).

Рисунок 9 – Основное окно программы Delphi 7

Для начала создадим форму авторизации пользователей. Для логина мы будем использовать компонент Combobox, для пароля – компонентEdit, для входа в систему – компонент Button, для загрузки входа в систему – компонент Timer и ProgressBar.

В компоненте Combobox для добавления списка необходимо щелкнуть назначок<…> в свойстве Items.

Рисунок 11 – Работа со свойством Items в компоненте ComboBox

Затем создадим главную форму. В главной форме добавим компонент «MainMenu».В компоненте MainMenu для добавления списка меню необходимо щелкнуть на значок <…>в свойстве Items.

Рисунок 12 – Работа со свойством Items в компоненте MainMenu

Рисунок 13 – Настройка компонента MainMenu

Для удобства размещения компонентов используется модуль хранения компонентов данныхDataModule. Компонент DataModuleпредназначен исключительно для размещения на нем невизуальных компонент для доступа к данным.

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

Рисунок 14 - Окно DataModule

Для связи интерфейсаcБД, созданной в MSAccess, предусмотренкомпонент ADOConnection,находящийся на вкладкеADO. Для подключения к базе компонент размещается на форме и в свойстве LoginPrompt ставится False, чтобы при подключении пароль не запрашивался. Это делается только на этапе создания интерфейса. Далее в свойстве ConnectionStringнужно нажать на значок «…», в открывшемся окне необходимо выбрать UseConnectionStringи нажать кнопку Build.В появившемся окне на вкладке «Поставщик данных» нужно выбрать провайдера MicrosoftJet 4.0 OLE DB Provider, на вкладке Подключение в соответствующем поле нужно ввести имя базы данных. Затем необходимо свойство Connectedпоставить в значение Trueдля соединения с программой MSAccess.

Рисунок 15 – ConnectionString

Рисунок 16 –Свойства подключения

Для подключения к конкретной таблице в БД, используется компонент ADOTable, вкладка ADO. В свойстве Connection нужно выбрать ADOConnectionи свойство Activeпоставить в положение True. (см. страница 23)

Для того, чтобы другие компоненты Delphi могли подключаться к таблицам (черезADOTable), используется компонент DataSource, находящийся на вкладкеDataAccess. В свойстве DataSet нужно выбрать соответствующий компонент ADOTable. (см. страница 24)

Для отображения данных БД в форме таблицы, используется компонент DBGrid, находящийся на вкладке DataControls.В свойстве DataSource выбирается соответствующий компонент DataSource (см. страница 22).

Для ввода полей БД в форме таблицы используется компонент DBEdit, находящийся на вкладке DataControls.В свойстве DataSource выбирается соответствующий компонент DataSource.Основным отличием DBEdit является наличие свойства DataSource, при помощи которого они связываются с источником данных. Еще одно свойство DataField указывает на то поле, которое должно отображаться в данном компоненте(см. страница 29).

Для связи одной таблице с другой таблицей используется компонент DBLookUPCombobox, находящийся на вкладке DataControls.В свойствеListSourceнужно выбрать соответствующий компонент DataSourceтаблицы-справочника, в свойстве ListFieldнужно выбрать соответствующее поле таблицы-справочника, в свойстве KeyFieldнужно выбрать ключевое поле. В свойстве DataSourceнужно выбрать соответствующий компонент DataSource конечной таблицы, в свойстве DataFieldнужно выбрать соответствующее поле конечной таблицы (см. страница 31).

Для даты и времени используется компонент DataTimePicker, находящийся на вкладке Win 32. В свойстве Date необходимо указать формат: дд.мм.гггг (см. страница 30).

Создаём остальные формы в программном интерфейсе.

Рисунок 17 – Форма сведений о программе

Для работы со справочником воспользуемся с программой Dr. Explain. При создании справочника появится окно выбора проекта (см. рисунок 18). В этом окне выберем создание локального проекта.

Рисунок 18 – Создание проекта

После этого появится рабочее поле проекта. В рабочем поле проекта присутствует две части: левая и правая, при этом левая часть делится ещё на две части (см. рисунок 19,20).

Рисунок 19- Создание структуры проекта

Рисунок 20- Информация о странице

В верхней левой части главного окна Dr.Explain можно задать непосредственно структуру документации, создавая новые темы и разделы в них. Для этого можно использовать как сочетания клавиш, так и щелчок правой кнопкой мыши по названию проекта. По умолчанию проект в Dr.Explain имеет три страницы: Начальная страница; Оглавление; <НЕ ЗАБЫТЬ: Имя темы>. Начальная страница содержит наименование проекта и указание на то, чем является файл (по умолчанию отображается значение «Руководство пользователя»).

Рисунок 21– Начальная страница

Рисунок 22- Интерфейс проекта

Создадим следующие разделы в справочнике (см. рисунок 23-27), затем скомпилируем программу ивыполним экспорт в файл формата (*.chm).

Рисунок 23– Руководство пользователя

Рисунок 24– Назначение программы

Рисунок 25– Условие выполнения программы

Рисунок 26– Выполнение программы

Рисунок 27– Сообщение оператору

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

ТЕСТИРОВАНИЕ И ОТЛАДКА

Классификация ошибок

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

В целом сложность отладки обусловлена следующими причинами:

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

Возможно взаимовлияние ошибок в разных частях программы, например, за счет затирания области памяти одного модуля другим из-за ошибок адресации;

Отсутствуют четко сформулированные методики отладки.

В соответствии с этапом обработки, на котором проявляются ошибки, различают:

Синтаксические ошибки - ошибки, фиксируемые компилятором (транслятором, интерпретатором) при выполнении синтаксического и частично семантического анализа программы;

Ошибки компоновки - ошибки, обнаруженные компоновщиком (редактором связей) при объединении модулей программы;

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

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

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

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

Появление сообщения об ошибке, зафиксированной схемами контроля выполнения машинных команд, например, переполнении разрядной сетки, ситуации «деление на ноль», нарушении адресации и т. п.;

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

- «зависание» компьютера, как простое, когда удается завершить программу без перезагрузки операционной системы, так и «тяжелое», когда для продолжения работы необходима перезагрузка;

Несовпадение полученных результатов с ожидаемыми результатами.

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

Неверное определение исходных данных,

Логические ошибки,

Накопление погрешностей результатов вычислений.

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

К последней группе относят:

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

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

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

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

Рисунок 28 - Ошибки выполнения

Отладка программы

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

– Ошибки компоновки – количество обнаруженных и исправленных синтаксических ошибок –1.

Рисунок 29–Отсутствие файла базы данных по указанному адресу

– Синтаксические ошибки – количество обнаруженных и исправленных синтаксических ошибок –5.

Рисунок 30–Поставлен знак «; » перед оператором else

– Ошибки выполнения - количество обнаруженных и исправленных ошибок выполнения –9.

Рисунок 31– Ошибка выполненияэкспорта в файл

Тестирование

Тестирование программного обеспечения– это процесс исследования, испытанияпрограммного продукта с целью получения информации о качестве продукта.

Существуют два принципа тестирования программы:

Функциональное тестирование (тестирование «черного ящика»);

Структурное тестирование (тестирование «белого ящика»).

Белый ящик – тестирование кода на предмет логики работы программы и корректности ее работы с точки зрения компилятора того языка, на котором она писалась.

Существуют следующие способы тестирования методом "Белого ящика":

Тестирование базового пути

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

Тестирование условий

Различают следующие виды тестирования:Простое условие - булева переменная или выражение отношения.Выражение отношения имеет вид:

Е1<оператор отношения>E2,

где El, Е2 - арифметические выражения, а в качестве оператора отношения используется один из следующих операторов: <, >, =, , .

Составное условие состоит из нескольких простых условий, булевых операторов и круглых скобок. Будем применять булевы операторы OR, AND (&), NOT. Условия, не содержащие выражений отношения, называют булевыми выражениями.

Тестирование циклов

Тестирование циклов производится по принципу «белого ящика», при проверке циклов основное внимание обращается на правильность конструкций циклов.

Различают 4 типа циклов: простой, вложенный, объединенный, неструктурированный.

Простые циклы. Для проверки простых циклов с количеством повторений п может использоваться один из следующих наборов тестов: прогон всего цикла; только один проход цикла; два прохода цикла; т проходов цикла, где т<п;п - 1, п, п + 1 проходов цикла.

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

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

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

Неструктурированные циклы - Неструктурированные циклы тестированию не подлежат. Этот тип циклов должен быть переделан с помощью структурированных программных конструкций.

При тестировании «черного ящика» рассматриваются системные характеристики программ, игнорируется их внутренняя логическая структура.

Тестирование «черного ящика» обеспечивает поиск следующих категорий ошибок:некорректных или отсутствующих функций;ошибок интерфейса;ошибок во внешних структурах данных или в доступе к внешней базе данных;ошибок характеристик (необходимая емкость памяти и т. д.);ошибок инициализации и завершения.

Существует три способа тестирования «черного ящика»:

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

Способ анализа граничных значений. Большая часть ошибок происходит на границах области ввода, а не в центре. Анализ граничных значений заключается в получении тестовых вариантов, которые анализируют граничные значения. Данный способ тестирования дополняет способ разбиения по эквивалентности.