Дипломная работа: Программное обеспечение управления автоматизированным комплексом многоканальной связи

Введение

Данный дипломный проект выполнен на актуальную для предприятий-производителей устройств связи тему, тесно связанную с реальными планами исследований и производства, решая практическую задачу по разработке и внедрению программного обеспечения управления автоматизированным комплексом многоканальной связи. По своему характеру проект является опытно-конструкторским. Разработанное обеспечение для изделия ТС16Е1 полностью удовлетворяет техническому заданию. По своему содержанию дипломный проект соответствует современному уровню науки и техники.

В процессе решения задачи создания программного продукта детально были рассмотрены особенности разработки программного обеспечения для микропроцессорных систем, устройство и принципы работы микропроцессоров серии МК51 вообще, интерфейсы в системах связи, основы асинхронной последовательной связи, общие методы ввода / вывода через коммуникационный порт и изучен информационный обмен контроллер-ЭВМ с использованием интерфейса RS‑232. Подробное описание структуры программы, алгоритмов построения и работы всех трех ее частей дает полное представление о ее создании, использовании и принципах работы.

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

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

1. Специальная часть

1.1 Постановка задачи проекта

Целью представленного дипломного проекта является разработка программного обеспечения управления автоматизированным комплексом многоканальной связи, построенного на базе микроконтроллера AT89C51, представляющего собой высокопроизводительный микропроцессор, особенности которого будут рассмотрены ниже. Комплекс представляет собой 16 линейных интерфейсов, обеспечивающих связь через мультиплексор на входе и демультиплексор на выходе общего высокоскоростного канала связи. Каждый интерфейс является коммутатором связи еще нескольких десятков устройств связи. Структурная схема основных частей автоматизированного комплекса многоканальной связи представлена на рисунке 1.1.

Е1 Е3, Е4

Рис. 1.1. Структурная схема основных частей комплекса

Блок линейных интерфейсов состоит из 16 независимых коммутаторных устройств, работающих с сигналами на скорости Е1. Каждый интерфейс имеет в своем составе 8 управляющих регистров, которые отображают состояние его работы. При изменении условий работы интерфейса, состояния линии связи или неполадок в самом устройстве регистры изменяют свое содержимое, благодаря чему можно однозначно определить причину неисправности.

Блок управления обеспечивает передачу данных регистров линейных интерфейсов на внешнюю ПЭВМ. Основной частью блока управления является микроконтроллер АТ89С51. Связь организуется через последовательный порт процессора Р3 по RS‑232‑му интерфейсу.

Мультиплексор и демультиплексор являются блоками передачи сгруппированного сигнала со скоростью Е3, Е4, работая в режиме дуплекса. На принимающей стороне стоят зеркально такие же демультиплексор и мультиплексор соответственно.

Внешняя ПЭВМ , общаясь через последовательный порт микроконтроллера АТ89С51 с блоком управления, получает необходимую информацию о состоянии работы всех 16‑ти линейных интерфейсов, контролируя таким образом весь комплекс удаленно. Для самой ПЭВМ таких комплексов может быть несколько.

Разработанное программное обеспечение позволит контролировать нормальную работу комплекса, взаимодействуя с внешней ПЭВМ по RS‑232‑му интерфейсу. К данному программному продукту предъявляются следующие требования:

1. Программное обеспечение для процессора АТ89С51 должно быть разработано в соответствии с общим алгоритмом ПО изделия ТС16Е1;

2. Использовать ОЗУ данных процессора АТ89С51 для хранения карты памяти состояний части битов регистров CR1, CR2, TSR и PSR 16‑ти линейных интерфейсов по заданным адресам в заданном порядке;

3. Обеспечить своевременное обновление карты памяти состояний части битов регистров CR1, CR2, TSR и PSR всех интерфейсов;

4. Обеспечить передачу карты памяти состояний оговоренных регистров, взаимодействуя с внешней ПЭВМ, используя интерфейс RS‑232, через последовательный порт Р3.

1.2 Особенности разработки программного обеспечения для микропроцессорных систем

В устройствах управления объектами на основе МП аппаратные средства и программное обеспечение существуют в форме неделимого аппаратно-программного комплекса. При проектировании контроллеров приходится решать одну из самых сложных задач разработки, а именно задачу оптимального распределения функций контроллера между аппаратными средствами и программным обеспечением. Решение этой задачи осложняется тем, что взаимосвязь и взаимовлияние аппаратных средств и программного обеспечения в микропроцессорной технике претерпевают динамичные изменения. Если в начале развития МП – техники определяющим было правило, в соответствии с которым аппаратные средства обеспечивают производительность, а программное обеспечение – дешевизну изделия, то в настоящее время это правило нуждается в серьёзной корректировке. Так как МП представляет собой стандартный массовый логический блок, конкретное назначение которого определяет пользователь с помощью программного обеспечения, то с ростом степени интеграции и, следовательно, функционально-логических возможностей МП резко понижается стоимость изделия в пересчёте на выполняемую функцию, что в конечном итоге и обеспечивает достижение высоких технико-экономических показателей изделий на МП. При этом затраты на разработку программного обеспечения изделия в 2 – 10 раз превышают затраты на приобретение и изготовление аппаратных средств.

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

1. Анализ задачи и выбора аппаратных средств контроллера;

2. Разработка прикладного программного обеспечения;

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

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

1. От постановки задачи к исходной программе;

2. От исходной программы к объектному модулю.

Этап разработки «от исходной программы к объектному модулю» имеет целью получение машинных кодов прикладных программ, работающих в МП. Этот этап разработки прикладного программного обеспечения легко поддаётся формализации и поддержан всей мощью системного программного обеспечения МП, направленного на автоматизацию процесса получения прикладных программ. В состав средств системного программного обеспечения входят трансляторы с различных алгоритмических языков высокого уровня, ассемблеры, редакторы текстов, программы – отладчики, программы – документаторы, и т.д. Наличие всех этих системных средств придаёт инженерной работе на этом этапе проектирования контроллеров характер простого конструирования, без большого объёма творческой инженерной деятельности. Так как на конечном изделии имеются только «голый» МП и средства его сопряжения с объектом, то выполнять отладку разрабатываемого прикладного программного обеспечения на нём невозможно, и, следовательно, разработчик вынужден обращаться к средствам вычислительной техники для выполнения всех формализуемых стадий разработки: трансляции, редактирования, отладки, загрузки объектных кодов в программируемую постоянную память МП. Попутно отметим, что системные средства автоматизации разработки прикладных программ МП на этапе «от исходной программы к объектному модулю» широко распространены и существуют в среде операционных систем микроЭВМ и присутствуют в операционных системах персональных компьютеров как отдельные пакеты инженерных программ.

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

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

1.3 Использование контроллера АТ89С51

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

Рассмотрим микроЭВМ серии МК51 более подробно.

1.3.1 Основные программно-доступные устройства микроконтроллера АТ89С51

Основными программно-доступными устройствами микроконтроллера AT89C51 являются:

1) 8‑разрядный аккумулятор А;

2) 8‑разрядный вспомогательный регистр AВ;

3) триггеры признаков результата: C, OV, P, отрицательности, нуля;

4) триггеры выбора банка рабочих регистров RS0 и RS1;

5) триггер программно-управляемого флага F0;

6) 16‑разрядный счетчик команд PC;

7) 16‑разрядный регистр указателя данных DPTR;

8) 8‑разрядный регистр указателя стека SP;

9) внутренняя память программ емкостью 4 Kb, расширяемая внешними устройствами до 64 Kb;

10)внутренняя память данных емкостью 128 байт, в которой размещается от одного до четырех банков рабочих регистров R0‑R7, область стека и побитово адресуемая область памяти;

11)внешняя память данных емкостью до 64 Kb;

12)два программируемых 16‑разрядных таймера-счетчика;

13)программируемый двунаправленный последовательный порт ввода-вывода и соответствующие устройства управления;

14)четыре 8‑разрядных двунаправленных параллельных порта ввода-вывода;

15)двухуровневую приоритетную систему прерываний с пятью векторами и двумя уровнями;

16)последовательный интерфейс;

17)тактовый генератор.

1.3.2 Структурная схема микроЭВМ серии МК51

Система команд микроЭВМ серии МК51 содержит 111 базовых команд с форматом 1, 2 или 3 байта. Микроконтроллер имеет:

· 32 РОН;

· 128 определяемых пользователем программно-управляемых флагов;

· набор регистров специальных функций.

РОН и определяемые пользователем программно-управляемые флаги расположены в адресном пространстве внутреннего ОЗУ данных.

Важнейшей и отличительной чертой архитектуры семейства МК51 является то, что АЛУ может наряду с выполнением операций над 8‑разрядными типами данных манипулировать одноразрядными данными. Отдельные программно-доступные биты могут быть установлены, сброшены или заменены их дополнением, могут пересылаться, проверяться и использоваться в логических вычислениях. Тогда как поддержка простых типов данных может с первого взгляда показаться шагом назад, это качество делает микроЭВМ семейства МК51 особенно удобным для применений, в которых используются контроллеры. Алгоритмы работы последних по своей сути предполагают наличие входных и выходных булевых переменных, которые сложно реализовывать при помощи стандартных микропроцессоров. Все эти свойства в целом называются булевым процессором семейства МК51. Благодаря такому мощному АЛУ набор инструкций микроЭВМ семейства МК51 одинаково хорошо подходит как для применений управления в реальном масштабе времени, так и для алгоритмов с большим объёмом данных.

Рис. 1.2а. Структурная схема МК51

Рис. 1.2б. Структурная схема МК51

Блок управления предназначен для выработки синхронизирующих и управляющих сигналов, обеспечивающих координацию совместной работы блоков микроЭВМ семейства МК51 во всех допустимых режимах её работы. В состав блока управления входят устройство выработки временных интервалов, логика ввода-вывода, регистр команд, регистр управления потреблением, дешифратор команд, ПЛМ и логика управления ЭВМ.

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

Логика ввода-вывода предназначена для приёма и выдачи сигналов, обеспечивающих обмен информацией ОМЭВМ с внешними устройствами через порты ввода-вывода Р0‑Р3.

Регистр команд предназначен для записи и хранения 8‑разрядного кода операции выполняемой команды, который с помощью дешифратора команд преобразовывается в 24‑разрядный код для ПЛМ, с помощью которой вырабатывается набор микроопераций в соответствии с микропрограммой выполнения команды. Регистр команд программно недоступен.

Регистр управления потреблением PCON управляет скоростью передачи последовательного порта SMOD.

Логика управления ЭВМ в зависимости от режима работы МИКРОЭВМ СЕМЕЙСТВА МК51 вырабатывает необходимый набор управляющих сигналов.

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

Регистр аккумулятора и регистр временного хранения – восьмиразрядные регистры, предназначенные для приёма и хранения операндов на время выполнения операций над ними. Программно недоступны.

ПЗУ констант обеспечивает выработку корректирующего кода при двоично-десятичном представлении данных, кода маски при битовых операциях и кода констант.

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

Регистр В- восьмиразрядный регистр, используемый во время операций умножения и деления. Для других инструкций он может рассматриваться как дополнительный сверхоперативный регистр.

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

Регистр состояния программы предназначен для хранения информации о состоянии АЛУ при выполнении программы.

Таймеры / Счётчики предназначены для подсчёта внешних событий, для получения программно-управляемых временных задержек и выполнения времязадающих функций ОМЭВМ.

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

Счётчик команд предназначен для формирования текущего 16‑разрядного адреса внешней памяти данных.

Порты Р0, Р1, Р2, Р3 являются двунаправленными портами ввода-вывода и предназначены для обеспечения обмена информацией микроЭВМ семейства МК51 с внешними устройствами.

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

Память программ предназначена для хранения программ и имеет отдельное от памяти данных адресное пространство объёмом до 64 Кбайт.

1.3.3 Адресные пространства АТ89С51

В AT89C51 имеются следующие адресные пространства:

1. Пространство адресов регистров специальных функций, таких как аккумулятор А, вспомогательный регистр AВ, старший и младший регистры указателя данных DPTR, фиксаторы портов ввода-вывода P0‑P3, регистр слова состояния программы PSW, регистр указателя стека SP и др. Диапазон адресов регистров специальных функций находится в пределах от 128 до 255. При записи данных по адресу регистра несуществующей специальной функции данные теряются, при считывании из регистра несуществующей специальной функции данные не определенны;

2. Пространство адресов триггеров специальных функций, таких как триггеры признаков переноса C, переполнения OV, четности P, отрицательности N, нуля Z, триггеры выбора банка рабочих регистров RS0 и RS1; триггер программно-управляемого флага F0 и другие. Все триггеры специальных функций физически размещаются в регистрах специальных функций. Наличие триггеров специальных функций определяется типом микроконтроллера. Диапазон адресов триггеров специальных функций находится в пределах от 128 до 255. Части адресов соответствуют несуществующие триггеры. При записи бита по адресу несуществующего триггера этот бит теряется, при считывании бита из несуществующего триггера его значение неопределенно;

3. Пространство адресов памяти программ. Диапазон адресов этого пространства находится в пределах от 0 до 65535. Память программ с адресами от 0 до 4096 может реализоваться внутренним запоминающим устройством. В пространстве адресов памяти программ размещаются коды команд и, возможно, данные. Часть адресов пространства памяти программ зарезервирована для точек входа в программу начального запуска и программы обслуживания прерываний. Адрес команды, подлежащей выполнению, хранится в счетчике команд PC. Обращение к данным в памяти команд осуществляется по адресу равному сумме содержимого счетчика команд PC и аккумулятора A или регистра указателя данных DPTR и аккумулятора A;

4. Пространство адресов внешней памяти данных. Диапазон адресов этого пространства находится в пределах от 0 до 65535. Во внешней памяти данных могут размещаться только данные, обращение к которым осуществляется посредством содержимого рабочего регистра-указателя R0, R1 или регистра указателя данных DPTR;

5. Пространство прямых адресов внутренней памяти данных. Диапазон адресов этого пространства находится в пределах от 0 до 127. Обращение к данным в пространстве прямых адресов осуществляется посредством второго байта кода команды. Пространство адресов регистров специальных функций является продолжением данного пространства;

6. Пространство косвенных адресов внутренней памяти данных. Диапазон адресов этого пространства находится в пределах от 0 до 127. Пространство косвенных адресов от 0 до 127 физически совпадает с пространством прямых адресов;

7. Пространство поразрядных прямых адресов внутренней памяти данных. Диапазон адресов этого пространства находится в пределах от 0 до 127. Данное пространство физически совпадает с пространством прямых адресов ячеек от 32 до 47. Пространство адресов триггеров специальных функций является продолжением пространства поразрядных прямых адресов;

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

MOV SP, #<адрес>;

9. Пространство рабочих регистров, которое разделено на 4 банка. Каждый из банков содержит восемь 8‑разрядных рабочих регистров R0 – R7. Диапазоны адресов пространства рабочих регистров во внутренней памяти данных следующие:

Для нулевого банка: 0 – 7;

Для первого банка: 8 – 15;

Для второго банка: 16 – 23;

Для третьего банка: 24 – 31.

Выбор текущего банка рабочих регистров определяется содержимым триггеров специальных функций RS0 и RS1:

Установить триггеры в требуемое состояние можно, например, посредством команд CLR RS0, CLR RS1, SETB RS0 и SETB RS1. Рабочие регистры R0 и R1 текущего банка могут использоваться при косвенной адресации внутренней и внешней памяти данных.

Адресам памяти текущего банка рабочих регистров R0‑R7 в языке ассемблера присвоены символические имена AR0‑AR7 соответственно. Распределение памяти ОЗУ процессора АТ89С51 представлено на рисунке 1.3.

Рис. 1.3. Распределение памяти ОЗУ процессора АТ89С51

1.3.4 Характеристики средств языка ассемблера

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

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

В зависимости от устройства памяти и способа адресации данных в этой памяти сегменты исходного модуля делятся на 4 типа:

· CODE, который используется для определения команд, данных и адресов в пространстве памяти команд;

· XDATA, который используется для определения адресов в пространстве внешней памяти данных;

· DATA, который используется для определения прямых адресов в пространстве внутренней памяти данных;

· IDATA, который используется для определения косвенных адресов в пространстве внутренней памяти данных;

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

При описании перемещаемого сегмента ему присваивается имя и тип, а также определяется способ его объединения с одноименными сегментами, описанными в других исходных модулях. Абсолютным сегментам присваивается только тип. Они не могут быть объединены с другими сегментами.

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

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

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

1.4 Интерфейсы в системах связи

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

1.4.1 Классификация интерфейсов

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

Межкрейтовые интерфейсы. В начале 70‑х годов фирма Hewlett-Packard разработала восьмибитовое параллельное устройство сопряжения – «Hewlett-Packard Interface Bus» – для связи между измерительными приборами и управляющим компьютером на расстояниях до 20 м. И со скоростью до 1Мбит/с. В 1975 г. HP-IB был приведен IEEE к национальному стандарту США IEEE‑488, а в 1987 г. Опубликована его последняя версия: IEEE‑488.2. Международная электротехническая комиссия выпустила аналогичный стандарт в ноябре 1976 г. В России этот тип интерфейса стандартизован ГОСТ 26.003–80 «Система интерфейса для измерительных устройств с байт последовательным, бит параллельным обменом информацией» и известен также под названием «приборный интерфейс» и «канал общего пользования». Стандарт IEEE‑488 получил широкое распространение и поддерживается почти всеми производителями измерительных приборов. Он даёт возможность объединять до 15 различных приборов в локальную измерительную систему, управляемую компьютером.

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

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

В настоящее время существуют несколько широко используемых интерфейсов: RS‑232C/V.28, EIA‑232D/V.28, RS‑423, -422, – 485. Эти стандарты регламентируют обмен данными в последовательном канале на физическом уровне. Они учитывают особенности линии связи, рекомендуют оптимальные схемы соединения, оптимальные характеристики приёмников и передатчиков. Принципиальное различие перечисленных интерфейсов состоит в используемом типе линий связи. В этом отношении интерфейсы можно разделить на однопроводной, несимметричный, дифференциальный и симметричный дифференциальный.

К стандартам, описывающим однопроводной интерфейс, относятся EIA RS‑232C, EIA‑232D, аналогичные европейские спецификации CCITT V.24, V28 и рекомендация ISO 2110, а также российские ГОСТ 18145–81, 23675–79.

Первоначально интерес RS‑232 был разработан для сопряжения терминалов с модемами. Сейчас этим интерфейсом комплектуется большинство популярных компьютеров для связи с внешними устройствами, в том числе и персональные компьютеры IBM PC. Поскольку ядром любой современной измерительной системы служит компьютер, использование штатного машинного интерфейса – наиболее простой и дешёвый способ организации связи в рассредоточенной системе.

1.4.2 Основы асинхронной последовательной связи

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

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

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

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

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

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

Рис. 1.4. Представление в асинхронной последовательной связи формата одиночного символа. A‑длительность 1 бита; B-MARK или 1; C-SPACE или 0

Как передатчик узнают о длительности каждого бита? Действительно, и передатчик, и приемник должны знать его длительность или детектирование битов будет невозможно. Длительность каждого бита определяется генераторами тактовых импульсов приемника и передатчика. Отметим, однако, что генераторы в приемнике и передатчике должны иметь одну и ту же частоту, но не требуется, чтобы они были синхронизированы. Выбор частоты генератора зависит от скорости передачи в бодах, которая означает число изменений состояния линии каждую секунду. Номинально тактовая частота «16‑кратная скорость передачи в бодах» означает, что линия проверяется достаточно часто для надежного распознавания стартового бита.

Существует одно обычное состояние линии, которое иногда используется для привлечения внимания приемника. Нормальным состоянием линии является MARK и начало символа определяется переходом SPACE. Если линия находится в состоянии SPACE в течение периода времени большем, чем время, которое она затратила бы на получение всех битов символа, тогда мы говорим, что наступило состояние BREAK. В кодах ASCII отсутствует представление BREAK – это означает, что линия «умерла» на непродолжительный промежуток времени, который составляет BREAK.

Ранее мы упоминали, что бит контроля четности полезен для обнаружения ошибок. Например, если выбрана проверка на четность, этот бит устанавливается таким образом, что общее число единиц в текущем слове является четным. В приемнике четность вычисляется заново и сравнивается с битом контроля четности. Если они не равны, то приемник сообщает, что имеет место ошибка четности. Главный недостаток обнаружения ошибки посредством проверки на четность заключается в том, что можно только обнаружить ошибки, которые влияют на один единственный бит. Например, битовая комбинация 0100 0001 0, переданная восемью битами с проверкой на четность, может измениться на 0100 01110, однако приемник не обнаружит ошибку, так как проверка на четность выполняется.

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

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

1.5 Общие методы ввода / вывода через коммуникационный порт

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

Большой проблемой для упорядоченного ввода / вывода через коммуникационный порт является то, что при скорости передачи выше 300 бод программе трудно что-либо сделать с получаемым символом кроме как отображать его на экране. Рассмотрим следующий пример. Предположим, что мы читаем символы со скоростью 300 бод и имеем следующие связные параметры: длина слова 7 бит, проверка на четность и один стоповый бит, который вместе со стартовым битом, добавляет до 10 бит на символ. Ожидается получать около 30 символов каждую секунду. После чтения символа программа имеет около 1/30 секунды для выполнения других операций. Чтобы не потерять какие-либо символы в это время следует снова начать упорядочение порта. Что произойдет, когда скорость возрастет до 9600 бод? Временной интервал между символами слишком мал для выведения символа на экран дисплея, не позволяет интерпретировать специальные символы и эмулировать терминал.

В подходе, основанном на управлении прерываниями, программа предоставляет возможность прерываниям устройства ввода / вывода поступать непосредственно на центральный процессор, который продолжает выполнять свою работу, не связываясь с устройством. Когда устройство готово к вводу / выводу, оно сигнализирует об этом центральному процессору посредством аппаратуры. Получив этот сигнал, центральный процессор сохраняет свое текущее состояние и вызывает подпрограмму обслуживания прерываний, адрес которой хранится в таблице векторов прерываний. Эта подпрограмма выполняет операцию ввода / вывода, затем восстанавливает состояние машины и возвращается в прерванную программу. Также стоит учитывать регистр символов, поступающих в коммуникационный порт персонального компьютера. Организовав где-нибудь некоторые ячейки памяти, можно использовать простую подпрограмму обработки прерываний, которая быстро считывает символ из коммуникационного порта и сохраняет его в следующей доступной ячейке памяти в буфере. Символы не будут утеряны в процессе считывания и сохранения символа драйвером прерываний перед поступлением следующего символа. Эта несложная задача достаточно проста для выполнения в короткие временные интервалы между поступающими символами при скорости передачи 9600 бод. Прелесть этого метода заключается в том, что время обработки главной программой символов, хранящихся в буфере, не имеет значения. Конечно, существует риск переполнения буфера, но эта проблема может быть решена простым увеличением его размера. Если этот способ не очень хорош, то для избежания переполнения буфера можно использовать управление потоком с помощью XON/XOFF.

Из этих рассуждений становится очевидно, что управляемая прерываниями буферная связь с использованием управления потоком с помощью XON/XOFF, предпочтительнее упорядоченной связи.

1.5.1 Последовательный порт с точки зрения программиста

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

1,843,200

делитель = –––––––––––––––––––––––––––––––

16 Х скорость передачи в бодах

Чтобы установить скорость передачи в бодах, Вы должны проделать следующее:

1. Установить в 1 наиболее значимый бит регистра управления линией.

2. Загрузить младший и старший байты делителя соответственно в приемный буфер и регистр разрешения прерываний.

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

Применяя этот подход, можно установить любое значение скорости передачи в бодах. Максимально возможной скоростью передачи является 1/16 тактовой частоты, или 115,200 бод. Этот предел вытекает из того, что делитель не может быть меньше единицы.

1.6 Информационный обмен контроллер – ЭВМ с использованием интерфейса RS‑232

Для связи МК51 с интерфейсом RS‑232 можно использовать самый подходящий для этого вариант – последовательный порт.

Последовательный порт микроЭВМ семейства МК51 может использоваться в виде регистра сдвига для расширения ввода-вывода или в качестве универсального асинхронного приемопередатчика с фиксированной или переменной скоростью последовательного обмена и возможностью дуплексного включения. Последовательный порт может принимать очередной байт, даже если уже принятый до этого байт не был прочитан из регистра приёмника. Однако если до окончания приёма, находящийся в регистре приёмника байт не будет прочитан то принятый байт теряется. Программный доступ к регистрам приёмника и передатчика осуществляется обращением к регистру специальных функций SBUF. При записи в SBUF байт загружается в регистр передатчика, а при чтении SBUF байт читается из регистра приёмника.

Приём и выдача байта данных начинается с младшего разряда и заканчивается старшим разрядом. Для разрешения приёма необходимо установить 1 в разряде REN регистра управления SCON.

Последовательный порт может быть запрограммирован на один из четырёх режимов приёма / передачи путём программирования разрядов SM0 и SM1 регистра SCON. Во всех четырёх режимах передача инициируется любой командой, которая использует SBUF в качестве регистра назначения.

Режим 0 . В этом режиме информация и передаётся и принимается через внешний вывод входа приёмника. Принимаются или передаются 8 бит данных. Через внешний вывод выхода передатчика выдаются импульсы сдвига, которые сопровождают каждый бит. Частота передачи бита информации равна 1/12 частоты резонатора.

Режим 1 . В этом режиме передаются через TXD или принимаются из RXD 10 бит информации: старт бит, 8 бит данных и стоп-бит. Скорость приёма / передачи – величина переменная и задаётся таймером.

Режим 2 . В этом режиме через TXD передаются или из RXD принимаются 11 бит информации: старт бит, 8 бит данных, программируемый девятый бит и стоп-бит. При передаче девятый бит может принимать значение 0 или 1, или, например, для повышения достоверности передачи путём контроля по чётности в него может быть помещено значение признака паритета из слова состояния программы. Частота приёма / передачи выбирается программой и может быть равна либо 1/32, либо 1/64 частоты резонатора в зависимости от управляющего бита SMOD.

Режим 3 . Режим 3 совпадает с режимом 2 во всех деталях, за исключением частоты приёма / передачи, которая является величиной переменной и задаётся таймером.

Передача начинается в фазе S1P1 машинного цикла, следующего за ближайшим после ЗАПИСЬ В SBUF переполнением делителя на 16 в цепи сигнала СИНХР Тх. Период сигнала СИНХР Тх определяет время, в течение которого выдаваемый бит присутствует на выходе TxD. Внутренние сигналы микроЭВМ семейства МК51 ПОСЫЛКА, ДАННЫЕ и СДВИГ по функциональному назначению и формированию идентичны во всех режимах. На выход TxD выдается девять бит данных: D0‑D7 и TB8. После первого импульса СДВИГ в освободившийся девятый разряд регистра сдвига передатчика заноситься 1. Всего формируется 9 импульсов СДВИГ, в результате чего все биты регистра сдвига передатчика последовательно выдаются на выход TxD. По окончании выдачи всех бит посылки блок управления передачей устанавливает флаг прерывания передатчика TI и снимает сигналы ПОСЫЛКА и ДАННЫЕ.

Приём начинается при обнаружении перехода сигнала на входе RxD из 1 в 0. Для отслеживания такого перехода вход RxD аппаратно опрашивается с частотой f1. Когда переход обнаружен, немедленно сбрасывается счетчик делитель на 16 в цепи сигнала СИНХР Rx, в результате чего происходит совмещение моментов переполнения этого счётчика делителя с границами смены битов принимаемой посылки на входе RxD. Шестнадцать состояний счётчика-делителя делят время, в течение которого каждый бит принимаемой посылки присутствует на входе RxD, на 16 фаз, с 1 по 16 для каждого бита. В фазах 7, 8 и 9 специальное устройство ОМЭВМ, бит-детектор, считывает с входа RxD 3 значения принимаемого бита, по мажоритарному принципу «2 из 3» выбирает из них одно и подаёт его на вход регистра сдвига приёмника. Блок управления приёмом при этом формирует внутренний импульс МИКРОЭВМ СЕМЕЙСТВА МК51 СДВИГ, в результате чего содержимое регистра сдвига приёмника сдвигается на один разряд и принятый бит заносится в регистр сдвига приёмника. После 10 импульса СДВИГ блок управления приёмом загружает биты D0‑D7 из регистра сдвига приёмника в SBUF, переписывает 9 разряд регистра сдвига приемника в бит RB8 регистра SCON и устанавливает флаг прерывания приёмника RI в регистре SCON. Сигнал загрузки SBUF, RB8 и установки RI вырабатывается блоком управления приёмом тогда и только тогда, когда в момент генерации последнего импульса СДВИГ выполняются следующие условия: RI=0 и либо SM2=0, либо принятый 9 бит данных равен 0.

Если хотя бы одно из этих условий не выполняется, принятая посылка безвозвратно теряется, а флаг RI не устанавливается. Если оба приведённых условия выполнены, принятый 9 бит данных поступает в RB8, биты D0‑D7 записываются в SBUF и устанавливается флаг RI. Независимо от выполнения приведённых выше условий последовательный порт вновь начинает отслеживание перехода сигнала из 1 в 0 на входе RxD. Значение принятого стоп-бита не влияет на SBUF, RB8 или RI.

Обмен между контроллером и ЭВМ производится в режиме полудуплекса, т.е. ЭВМ посылает байт, а контроллер отвечает. С ЭВМ по каналу RS‑232 приходит байт с установленным девятым битом, это означает что необходимо начать преобразование входного сигнала. Второй и последующий байты посылаемые ЭВМ приводят к выталкиванию двух оцифрованных значений побайтно, старшими байтами вперёд, т.е. если первое слово обозначить H0L0, а второе H1L1 то они будут переданы так: H0, L0, H1, L1. Затем контроллер передаёт контрольную сумму, которая подсчитывается по формуле: CRC = S + H0 + L0 + H1 + L1. Она служит для контроля за правильностью передачи данных. После передачи контрольной суммы контроллер переходит в исходное состояние в котором он может принимать только байты с девятым битом равным единице.

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

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

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

1. Надежность;

2. Простота реализации;

3. Точность;

4. Скорость работы.

1.7.1 Структуры данных

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

1.7.2 Составляющие программы

Программа управления автоматизированным комплексом многоканальной связи состоит из трех частей: основная программа, подпрограмма перезаписи карты памяти части битов внутренних регистров CR1, CR2, TSR и PSR линейных интерфейсов, которая выполняется с приходом прерывания от любого линейного интерфейса и подпрограмма связи с внешней ПЭВМ через последовательный порт, которая выполняется, когда приходит прерывание от последовательного порта.

Система прерываний для микроконтроллера АТ89С51 организована следующим образом. При приходе прерывания от последовательного порта, выполняется специальная подпрограмма обработки этого прерывания. Как она работает. Вначале производится проверка, и если приходит прерывание от передатчика, то сбросить его и выйти. Если нет, то производится проверка полученного байта, если пришёл байт с установленным 9 битом то выполняется инициализация процедуры чтения данных из памяти, затем подсчёт контрольной суммы, передача блока данных на ЭВМ и завершение подпрограммы. Если пришел байт без установленного 9 бита, то если переданы все байты – передаётся контрольная сумма, а если нет – передаётся байт и подсчитывается контрольная сумма.

В начале основной программы происходит назначение векторов прерываний от линейных интерфейсов и последовательного порта. Далее идут два блока инициализации: области памяти ОЗУ данных с 40Н по 7FН и самих линейных интерфейсов. Команды инициализации последних CR2.RESET формируются в соответствии с таблицей адресов линейных интерфейсов и таблицей адресов внутренних регистров линейных интерфейсов.

Рис. 1.10. Адреса внутренних регистров линейных интерфейсов.

Затем производится запись в ОЗУ данных состояний части битов внутренних регистров линейных интерфейсов. Данные располагаются в заранее оговоренной техническим заданием области памяти 40Н – 7FН в заданном порядке. Распределение памяти ОЗУ данных процессора показано на рисунке 1.11. Нужные биты выбираются из внутренних регистров линейных интерфейсов, таблица которых приведены на рисунке 1.12. Например, для занесения бита AIS в 1‑й бит ячейки памяти 40Н, его нужно считать из 2‑го бита регистра PSRLI1. Порядок сохраняется для всей карты по возрастанию следующий: PSR, TSR, CR2, CR1.

Рис. 1.11. Распределение памяти ОЗУ данных процессора.

Потом инициализируется последовательный порт Р3 на прием. Инициализируется таймер, выбор 1‑го таймера, перевод его в третий режим работы, загрузка константы скорости в таймер для 9600 Бод, разрешение работы таймера. Инициализация последовательного порта проходит следующим образом: порт устанавливается в режим 9‑бит с программируемой скоростью, устанавливается адрес для записи принятых значений, выбирается номера канала, идет разрешение приёма сообщений с взведённым 9‑м битом, разрешение работы приёмопередатчика, разрешение прерываний от приёмопередатчика, общее разрешение прерываний, сброс бита разрешения приёма. После этого выполняется основной цикл программы: ожидание прерывания либо от любого из линейных интерфейсов с переходом на подпрограмму перезаписи карты памяти части битов внутренних регистров линейных интерфейсов, либо от последовательного порта с переходом на подпрограмму связи с внешней ПЭВМ через последовательный порт.

Подпрограмма перезаписи карты памяти части битов внутренних регистров линейных интерфейсов состоит из четырех последовательных вызовов подпрограмм RDPSR, RDTSR, DRCR2 и RDCR1 с предварительным занесением в регистр R1 соответствующих адресов регистров, используя таблицу, приведенную на рисунке 1.10. Выполнение подпрограммы происходит в режиме маскирования прерываний. После перезаписи карты памяти снимаются все флаги прерываний линейных интерфейсов и происходит выход из подпрограммы.

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

1.7.3 Тестирование и отладка программы

После окончания этапа программирования, т.е. собственно процесса написания программы, проводится ее проверка для обнаружения и исправления возможных ошибок. На эмуляторе микропроцессора АТ89С51 проверяется корректность кода программы по содержимому различных регистров процессора. В контрольных точках программы, выбранных для удобства после каждого логически законченного куска кода, мы смотрим содержимое регистра R7. Внесенные в программу отладочные строки для контроля ее пошагового выполнения позволяют своевременно выявлять неточности реализации общего алгоритма изделия ТС16Е1. Применение модульного принципа тестирования программы существенно облегчает этот процесс.

Далее проверенный таким образом ассемблерный текст программы с помощью компилятора ассемблера микропроцессора АТ89С51 переводится в hex‑файл. На этом этапе так же можно проконтролировать возможные неточности кода. При дальнейшем переводе этого текста программы в машинный код, производится поиск синтаксических ошибок в программе и, в случае их обнаружения, печатается диагностика, помогающая последующей локализации ошибок. Отсутствие синтаксических ошибок не говорит о том, что в программе нет ошибок.

По окончании такой отладки программы начинается ее эксплуатация. С помощью программатора полученный машинный код прошивается в тестовой ПЗУ с ультрафиолетовым стиранием, и начинается тестирование опытного образца. Производится анализ работы системы в целом, обычно многократный. Первые полученные результаты реальных данных подвергаются тщательному анализу, чтобы убедиться в пригодности использованного метода и установить согласованность полученных результатов с имеющимися данными и теорией. Если правильность получаемых результатов не. вызывает сомнений и эффективность программы удовлетворительна, то ее эксплуатация продолжается. В случае отклонения результатов работы программы от ожидаемых, происходит возврат к поиску возможных ошибок на этапе кодирования общего алгоритма изделия ТС16Е1.

1.7.4 Оформление программы и ее возможная модернизация

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

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

1.7.5 Надежность программного продукта

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

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

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

· проверку исправности системы;

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

· проверку правильности функционирования в данном режиме работы в данный момент времени;

· поиск и локализацию неисправностей в системе.

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

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

В ходе выполнения данного дипломного проекта была разработана программа управления автоматизированным комплексом многоканальной связи. Предъявленные в техническом задании к проекту требования выполнены полностью: программное обеспечение для процессора АТ89С51 разработано в соответствии с общим алгоритмом ПО изделия ТС16Е1, ОЗУ данных процессора АТ89С51 использовано для хранения карты памяти состояний части битов регистров CR1, CR2, TSR и PSR 16‑ти линейных интерфейсов по заданным адресам в заданном порядке, обеспечено своевременное обновление карты памяти состояний части битов регистров CR1, CR2, TSR и PSR всех интерфейсов через подпрограмму обработки прерываний линейных интерфейсов, обеспечена возможность передачи карты памяти состояний оговоренных регистров, взаимодействуя с внешней ПЭВМ, используя интерфейс RS‑232, через последовательный порт Р3. Подробно описана структура программы, алгоритмы построения и работы всех трех ее частей для дальнейшего использования, модернизации и возможного применения отдельно взятых частей кода при разработке подобных программных продуктов для устройств связи.

2. Технологическая часть

2.1 Требования к программным системам

Каждая программа, входящая в систему, должна отвечать таким требованиям, как:

· правильность

· точность

· совместимость

· надежность

· универсальность

· защищенность

· полезность

· эффективность

· проверяемость

· адаптируемость

Будем говорить, что программа является:

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

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

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

· надежной, если она при всех условиях обеспечивает полную повторяемость результатов. Любой человек, имеющий опыт работы с ЭВМ, может подтвердить, что в его практике еще не встречалось ни абсолютно надежного системного программного обеспечения, ни безукоризненно работающих машин. И, несмотря на оптимистичность высказываний некоторых программистов, то же самое можно сказать о прикладных программных системах. Впрочем, уровень их надежности может быть повышен за счет использования встроенных механизмов резервирования и самоконтроля.

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

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

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

· эффективной, если объем требуемых для ее работы ресурсов ЭВМ не превышает допустимых пределов.

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

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

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

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

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

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

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

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

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

2.2 Этапы решения задачи на ЭВМ

1. Постановка задачи.

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

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

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

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

2. Составление проекта.

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

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

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

3. Алгоритмизация.

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

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

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

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

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

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

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

4. Программирование.

В случае, когда на предыдущем этапе был получен детально разработанный алгоритм, составление программы на выбранном для программирования языке сводится к переводу этого алгоритма на язык программирования. Основные трудности и, следовательно, причины ошибок на этом этапе заключаются, во-первых, в необходимости знания всех требований и ограничений выбранного языка программирования и, во-вторых, в необходимости постоянного внимания ко многим деталям языка, которые приходится учитывать в ходе написания программы. Если этап 3 был выполнен некачественно и алгоритм представлен недостаточно детально, то его доводку придется выполнять «на ходу», во время программирования. Это затруднит процесс программирования-перевода и поведет к возникновению дополнительных ошибок в программе. Чем более процесс программирования будет походить на перевод, чем более механическим будет такой перевод, тем более легким будет составление программы и тем меньше возникнет ошибок на этом этапе, самом щедром на ошибки.

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

1. Компиляция.

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

6. Отладка.

На этапе отладки производится обнаружение с помощью ЭВМ ошибок в программе и их исправление. Этап отладки можно разделить на три подэтапа:

6.1. Контроль правильности программы.

6.2. Локализация ошибок.

6.3. Исправление ошибок.

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

На этапе 6.2 – локализация ошибок – точно устанавливается место, где в программе допущена ошибка, последствия которой проявились при выполнении этапа 6.1.

На этапе 6.3 производится исправление ошибок, выявленных на этапе 6.2. Исправления вносятся как в программу, так и в алгоритм, если он затрагивается этими исправлениями.

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

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

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

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

8. Оформление программы.

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

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

9. Отчет о работе.

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

10. Модернизация.

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

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

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

2.3 Проектирование системы

К основным стадиям развития программной системы относятся следующие:

· постановка задачи;

· разработка;

· реализация;

· испытания;

· эксплуатация системы.

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

2.3.1 Определение основных элементов системы

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

2.3.2 Структурный анализ

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

2.3.3 Структурное проектирование

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

2.3.4 Реализация и испытания

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

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

В конечном итоге вся система в целом будет испытана и готова к внедрению в промышленную эксплуатацию.

2.4 Вспомогательные средства проектирования

2.4.1 Графическая схема задания

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

Рис. 2.2. Графическая схема задания.

2.4.2 Развернутый план проекта системы

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

A. Функции системы. Поясняется назначение прикладной системы, приводится перечень основных процедур и обрабатываемых данных.

B. Сфера применения. Характеризуется круг пользователей, на которых ориентирована разрабатываемая система.

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

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

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

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

B. Программные средства. Указываются типы операционных систем, используемые библиотеки стандартных программ, системы управления базами данных.

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

III. Связь с внешней средой. Описывается взаимодействие пользователей с системой.

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

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

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

D. Рабочие инструкции. Дается общий обзор содержания инструкций. Данная информация используется при составлении инструкций для обслуживающего персонала.

IV. Качество системы.

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

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

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

D. Защита информации. Описываются средства, обеспечивающие сохранность данных и авторизацию доступа, используемые способы кодирования.

V. Документация по системе.

A. Пособия и руководства. Приводится перечень документации, прилагаемой к системе, – пособий, форм отчетности, рабочих описаний, системной и программной документации.

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

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

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

2.5 Организация процесса проектирования

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

· составление рабочих спецификаций

· составление перечня характеристик

· внешнее описание данных

· внешнее описание программ

· разработка архивов данных

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

· разработка тестовых задач

· кодирование программных модулей

· проверка программных модулей

· объединение программных модулей

· испытание системы в целом

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

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

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

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

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

2.6 Необходимость тестирования программных продуктов

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

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

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

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

2.7 Отладка и общие принципы тестирования программ

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

Одним из самых сложных и трудоемких этапов технологического процесса разработки программ является их тестирование и отладка. Как известно, при создании типичного программного проекта около 50% общего времени и более 50% общей стоимости расходуется на проверку разрабатываемой системы и ее отладку.

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

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

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

Существует два основных подхода к тестированию:

Рис. 2.3. Технология отладки программ

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

2. Тестирование программы как «белого ящика». Стратегия белого ящика, или стратегия тестирования, управляемого логикой программы, позволяет использовать внутреннюю структуру программы. В этом случае программист получает тестовые данные путем анализа логики программы. Основной алгоритм тестирования программы представлен на рис. 2.3.

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

Алгоритмическое тестирование

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

Функциональное или аналитическое тестирование

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

Содержательное тестирование

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

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

2.8 Типы тестов

Рассмотрим несколько основных типов тестов программного обеспечения:

Вырожденный тест

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

Тест граничных значений

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

Аварийный тест

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

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

Стыковочные тесты

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

Комплексные тесты

Проверяют правильность работы всех или большинства частей программы после их объединения.

2.8.1 Модульное тестирование

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

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

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

2.9 Надежность программного обеспечения

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

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

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

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

2.9.1 Критерии надежности систем

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

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

P = P .

Соответственно вероятностью отказа является вероятность того, что в течение заданного времени произойдет хотя бы один отказ:

Q = P = 1 – P .

Частота отказов a есть плотность распределения времени работы до первого отказа:

.

Интегральным критерием является интенсивность отказов l, которая характеризует плотность распределения наработки до первого отказа, рассчитанную при условии, что до рассмотренного момента времени система проработала безотказно:

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

.

Аналогично можно представить другие характеристики, описывающие надежность для невосстанавливаемых систем при условии, что они уже функционировали в течение времени to :

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

· распределение наработки до i – го отказа: Fi = P ;

· распределение времени до i – го восстановления: Vi = P ;

· вероятность возникновения nотказов до достижения длительности наработки t : Pn .

Кроме того, отказы можно характеризовать средним числом H за время t , интенсивностью потока отказов w = d H / dt и наработкой на отказ T = t / H .

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

· вероятностью восстановления за время t ;

· плотностью распределения времени восстановления;

· средним временем восстановления.

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

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

2.9.2 Типы программного обеспечения с точки зрения надежности

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

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

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

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

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

2.9.3 Анализ надежности программного обеспечения

К задачам анализа надежности программного обеспечения можно отнести следующее:

· формулирование основных понятий, используемых при исследовании параметров и показателей надежности программ;

· выявление и исследование основных факторов, определяющих характеристики надежности сложных программных комплексов;

· выбор и обоснование критериев надежности комплексов программ различного типа и назначения;

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

· исследование ошибок в программах, динамики их изменения при отладке и модернизации и их влияния на надежность;

· разработка и исследование методов структурного синтеза сложных программ, повышающих их надежность;

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

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

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

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

2.9.4 Диагностика функционирования комплексов программ

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

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

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

· проверку правильности функционирования в данном режиме работы в данный момент времени;

· поиск и локализацию неисправностей в системе.

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

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

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

При тестовом диагнозе различаются прямая и обратная задачи.

2.9.5 Основные факторы, влияющие на надежность функционирования комплексов программ

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

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

· искажения исходной информации, поступающей от внешних абонентов;

· самоустраняющиеся отказы или сбои в аппаратуре вычислительной системы;

· невыявленные ошибки в комплексе программ.

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

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

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

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

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

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

2.10 Разработка программной документации

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

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

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

Рис. 2.4. Системная документация

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

II. Проектная документация. Эта часть документации готовится системным аналитиком, который руководствуется сведениями, полученными от программистов и будущих пользователей.

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

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

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

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

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

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

C. Руководство оператора. В руководстве содержатся описание вычислительной установки и конфигурации устройств, а также инструкции по работе с программной системой

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

A. Символьный код. Это набор текстов самодокументированных программ, составленных в удобной для восприятия форме.

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

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

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

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

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

3.Организационно-экономическая часть

3.1 Экономическая эффективность программного продукта

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

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

Э = Эо – Сs

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

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

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

В соответствии с этапами жизненного цикла ПО основные затраты Сs, снижающие идеальную эффективность за цикл жизни Тж, можно представить следующими составляющими:

· совокупные затраты на создание ПП и обеспечение решения заданных функциональных задач, в том числе на технологическое обеспечение и аппаратуру ЭВМ при разработке ПО в течение времени Тр – Ср;

· затраты на эксплуатацию программных и аппаратных средств, реализующих ПП, а также совокупные потери эффективности за время Тэ вследствие ограниченных характеристик ЭВМ и неидеальности программ – Сэ;

· затраты на сопровождение ПО за время Тс, включающие затраты на хранение и контроль состояния, проведение модернизаций и исправление ошибок, тиражирование версий – Сс;

· накладные расходы Сн.

В результате совокупную реальную эффективность функционирования ПО за весь жизненный цикл длительностью Тж можно представить в виде:

Э = Эо – Ср – Сэ – Сс – Сн.

3.2 Составляющие затрат на создание программного продукта

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

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

· на непосредственное проектирование, программирование, отладку и испытания программ в соответствии с требованиями пользователя или заказчика – С1 р;

· на изготовление опытного образца ПП как продукции производственно-технического назначения – С2 р;

· на разработку, подготовку и применение технологии программных средств автоматизации разработки программ – С3 р;

· на технологические и реализующие ЭВМ, используемые для автоматизации разработки программ – С4 р;

· на подготовку и повышение квалификации специалистов-разработчиков – С5 р.

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

3.2.1 Затраты на непосредственную разработку ПП

Затраты на непосредственную разработку комплекса программ С1 р являются важнейшей составляющей в жизненном цикле ПП. Наибольшее влияние на них оказывает объем ПП. Затраты на разработку С1 р и объем программ Пк связаны через показатель интегральной средней производительности труда разработчиков Р. Для учета влияния на С1 р различных факторов удобно пользоваться коэффициентами изменения трудоемкости – Сij, учитывающими зависимость i‑ой составляющей совокупных затрат от j‑го фактора. Непосредственные затраты на разработку можно представить как частное от объема ПП и производительность труда, корректируемое произведением коэффициентов изменения трудоемкости:

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

* факторы, отражающие особенности создаваемого комплекса программ как объекта разработки, и требования к его общим характеристикам;

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

* факторы, отражающие оснащенность процесса создания ПП аппаратурными средствами, на которых базируются системы автоматизации разработки;

* факторы, определяющие оснащенность процесса разработки программ и его обеспечение квалифицированными специалистами.

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

Факторы ПП как объекта проектирования, влияющие на непосредственные затраты при разработке сложных программ.

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

3.2.2 Сложность разработки программного продукта

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

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

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

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

Ограничение ресурсов производительности и оперативной памяти реализующей ЭВМ. При использовании создаваемым ПП производительности и памяти реальной ЭВМ менее чем на 50% можно не учитывать эти ограничения.

где р – реальная загрузка ЭВМ.

Длительность предполагаемой эксплуатации ПП изменяется от нескольких месяцев до нескольких лет. По экспертным оценкам, увеличение предстоящей длительности эксплуатации ПП на порядок от 1 до 10 лет приводит к увеличению КИТ С15 примерно в 1.5–2 раза. Такую зависимость можно описать логарифмической функцией:

где а15 изменяется в диапазоне от 1 до 0.5.

Предполагаемый тираж программ Nсоставляет

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

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

Мобильность использования ПП из других разработок позволяет снижать затраты при сборочном программировании новых ПП. При этом относительное повышение производительности труда пропорционально доле использования в новом ПП. При сборочном программировании кроме 10–20% затрат на создание новых программных компонент, необходимы ресурсы на комплексирование нового ПП, его комплексную отладку, испытания и документирование. В результате суммарные затраты заметно возрастают и эквивалентное повышение производительности труда С18 может составлять 2.5–3 раза. Необходимо учитывать затраты, которые требуются на создание адаптируемых компонент и всего первичного ПП. В результате программная мобильность с учетом затрат на ее подготовку в среднем дает снижение КИТ на 30–50%.

3.2.3 Затраты на изготовление опытного образца как продукции производственно-технического назначения

Затраты на изготовление опытного образца ПП как продукции производственно-технического назначения – С2 р определяется необходимостью обеспечить отчуждение всего комплекса программ от его непосредственных разработчиков. Удельный вес этих затрат находится в пределах 10–15% от общих затрат на разработку С1 р. Для изготовления ПП как продукции производственно-технического назначения необходимо:

· изготовить и оформить опытный образец ПП на носителях данных;

· разработать комплект документации, обеспечивающий квалифицированную эксплуатацию ПП.

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

3.2.4 Затраты на создание комплекта документации

Затраты на создание комплекта документации С2р2 практически пропорциональны объему программы:

,

,

где Д = 50–100 страниц документации на тысячу команд,

а2 – удельная трудоемкость страницы написания документации. В реальных ПП определяется по аналогичным разработкам.

3.2.5 Затраты на технологию и программные средства автоматизации разработки ПП

Затраты на технологию и программные средства автоматизации разработки ПП обычно являются весьма весовыми только при использовании автоматизированных технологий. Объем и сложность программного продукта значительно влияют на выбор уровня автоматизации технологии и долю затрат в общих затратах на разработку. Встречаются ситуации, при которых затраты на технологию достигают 50% общих затрат на разработку С1 р. В нашем случае подобных затрат нет, и поэтому ими можно пренебречь.

Затраты на ЭВМ, используемые для автоматизации разработки данного ПП – С4 р – включают капитальные затраты на закупку и установку соответствующих ЭВМ, а также текущие затраты на их эксплуатацию в течении разработки ПП.

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

С4 р = С4р1 = а41*Тр,

где а41 – стоимость машинного времени реализующей ЭВМ.

3.3 Составляющие затрат на эксплуатацию программ, влияющих на процесс разработки ПП

Затраты на эксплуатацию программ, влияющих на процесс разработки ПП:

* затраты на производство и внедрение экземпляра ПП – С1э

* затраты на реализующую ЭВМ – С2э

* затраты на эксплуатацию реализующей ЭВМ – С3э

* затраты на эксплуатацию экземпляра – С4э

* потери вследствие задержек и потерь сообщений – С5э

* потери вследствие сбоев и отказов ПП – С6э

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

Вторая составляющая затрат на эксплуатацию – С1э2 обусловлена подготовкой каждого образца ПП к конкретным условиям применения перед использованием. В нашем случае она равна нулю.

Затраты на внедрение – С1э3 можно снижать за счет эффективных средств обучения персонала. И в некоторых случаях обучение специалистов и внедрение экземпляра сложных ПС может требовать 2–7% общих затрат на разработку ПП. Поэтому в нашем случае С1э = С1э3.

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

Для ПП, работающих в реальном времени, при малом использовании периферийных устройств затраты на реализующую ЭВМ определяются в основном следующими факторами:

· объем оперативной По и командной Пк памяти ЭВМ – f2э1;

· быстродействие вычислительной системы f2э2;

· уровень технологии и автоматизации проектирования программ U, влияющий на степень использования ресурсов реализующей ЭВМ f2э3.

Как известно, память является одной из самых дорогих компонент вычислительной машины. Для размещения сложных программ объемом 104–107 команд стоимость ЭВМ практически пропорциональна суммарному объему памяти или объему памяти, необходимому для размещения ПП. Поэтому можно принять f2э1 = а2э*.

Вторым фактором, определяющим стоимость вычислительных систем, является их быстродействие или производительность. В некоторых пределах затраты на реализующие ЭВМ практически линейно зависит от логарифма величины быстродействия. Поэтому можно принять f2э2 = 2–3.

В нашем случае f2э3 = 1 из-за низкого уровня автоматизации.

В результате суммарные затраты на реализующую ЭВМ с определенным ПП можно описать следующим приближенным выражением:

С2э = f2э1 *f2э2,

где Б – быстродействие ЭВМ.

Коэффициент а2э учитывает текущее состояние технологии изготовления аппаратуры ЭВМ. Его можно оценить по техническим характеристикам и стоимости реальных вычислительных машин.

Затраты на эксплуатацию реализующей ЭВМ – С3э для комплекса программ в реальном времени практически постоянны в единицу времени и можно принять, что:

С3э = а3э*Тэ

Коэффициент а3э соответствует удельной стоимости машинного времени. Затраты на эксплуатацию экземпляра ПП на реализующей ЭВМ – С4э так же, как и предыдущие, можно считать прямо пропорциональными времени эксплуатации ПП – Тэ:

С4э = а4э*Тэ

Коэффициент а4э в основном зависит от типа памяти, используемой для хранения программ. Наименьшие затраты при эксплуатации программ требуются при использовании постоянных или полупостоянных запоминающих устройств. В этом случае удельные затраты за время жизненного цикла ПП обычно составляет малую долю от затрат на реализующую ЭВМ. Обычно а4э<<а3э, вследствие чего С4э может не учитываться.

Потери эффективности функционирования ПП вследствие задержек и потерь сообщений, подлежащих обработке, – С5э обусловлены ограниченностью ресурсов реализующей ЭВМ. Ограничение ресурсов отражается как непосредственно на разработке ПП, так и на его эксплуатации. Влияние этого ограничения в процессе разработки и приводит к необходимости тщательного учета и экономичного использования ресурсов реализующей ЭВМ, что увеличивает С14. Более тщательное проектирование ПП в условиях ограниченных ресурсов ЭВМ позволяет снизить потери С5э, однако увеличивает затраты за счет КИТ – С14. При единственном экземпляре эти затраты возможно учитывать за счет С14.

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

Сэ = С1э + С2э + С3э + С4э + С5э + С6э.

3.4 Составляющие затрат на сопровождение программ

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

Основными факторами, влияющими на процесс разработки ПП, являются:

· объем программного продукта

· длительность жизненного цикла ПП

· уровень технологии разработки ПП

· степень использования ресурсов реализующей ЭВМ

· надежность ПП

· число версий ПП

· мобильность ПП

· тиражность ПП

Затраты на сопровождение ПП сводятся к трем составляющим:

* на обнаружение и устранение ошибок в каждой версии ПП – C1с

* на доработку и совершенствование программ, формирование и испытание новых модернизированных версий ПП – C2с

* на тиражирование каждой новой версии ПП и ее внедрение в эксплуатируемых и новых системах – C3с.

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

Затраты на развитие и модернизацию программы C2с близки по содержанию к затратам на первичную разработку ПП Ср. Модернизация производится поэтапно и для каждой новой версии изменяется только некоторая часть от объема всего ПП. Обычно эта часть составляет не более 20% от всего комплекса. Сложность связей в ПП приводит к тому, что удельные затраты на изменяемые программы при модернизации каждой версии могут быть несколько больше, чем затраты на создание программ такого же объема при первичном проектировании. ПО управления автоматизированным комплексом многоканальной связи реализовано в виде машинного кода, специфика ассемблерного текста которого применительно к данной задаче исключает его модернизацию. В целом, цели и технические требования к таким ПП оговорены заранее. Подобные продукты разрабатываются в каждом случае под конкретную архитектуру. Поэтому, составляющая затрат на развитие и модернизацию такого ПО C2с также будет равна нулю.

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

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

3.5 Расчет затрат на программный продукт

Исходные данные:

– объем ПП составляет примерно 300 операторов на ассемблере;

– надежность функционирования ПП около 20 часов наработки на отказ;

– ограничение ресурсов производительности и оперативной памяти реализующей ЭВМ не менее 50%;

– длительность эксплуатации составит не менее 5 лет;

– данная программа будет существовать в единственном экземпляре;

– после создания ПП предполагается использовать около 40% наработок;

– при создании ПП число наработок из других программ составило не более 20%;

– в процессе проектирования велась пошаговая разработка компонент ПП с контролируемыми этапами технологии и поэтапным контролем результатов работ;

– при разработке ПП, который относится к ПП ниже среднего класса сложности применялась только реализующая ЭВМ, которая также использовалась для имитации внешней среды и тестов;

– на разработку и отладку произведенного ПП потребовалось в среднем по 0,3 Мбайта;

– уровень квалификации заказчика выше среднего.

Суммарные затраты:

Cs = Cp + Cэ + Сс + Сн

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

Сs = Ср + Сэ + Сн.

Рассчитаем каждое слагаемое.

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

Ср = С1 р + С2 р + С3 р + С4 р.

Факторы, влияющие на затраты при разработке

С1 р = Пк/Р * П Сij

С11 = lg = 1;

С13 = lg = 2.3;

С14 = 0.51;

С15 = а15*lg = 0.5*lg = 0.85;

С16 = 2.3;

С17 = 1.4;

С18 = 0.9;

С31 = 0.65;

С32 = 1;

С33 = 0.5;

С34 = 1;

С41 = 0.7;

С42 = 0.75;

С51 = С52 = 0.8;

С53 = 0.95;

С54 = 1.1;

Остальные коэффициенты примем равными единице.

Р – производительность = 60 команд на ассемблере в день

Пк = 300 команд

Зарплата составляет 150 руб./день

Рассчитаем С1 р.

С1 р = 3.131 * 150 = 470 рублей.

Затраты на изготовление опытного образца ПП

С2 р = а2 р * Д * Пк* Зарплата_в_день,

где а2 р = 1 день / 10 страниц;

Д – 50 страниц / 1000 команд;

С2 р = 6 * 150 = 900 рублей.

Затратами на технологию и программные средства мы пренебрегаем.

Затраты на ЭВМ

С4 р = а41*Тр

где а41 = 24000 / = 480 руб. / месяц

С4 р = 1 * 400 = 480 рублей.

Итак:

Ср = 470 + 900 + 480 = 1850 рублей.

Затраты на эксплуатацию программ

Сэ = С1э + С2э + С3э

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

С2э = а2э**lg

где

а2э = 0.005*5500*7 рублей

По + Пк = 0,5Мбайта

Б – быстродействие = 10 000 000 операций в секунду.

С2э = 190 рублей.

Затраты на эксплуатацию реализующей ЭВМ

С3э = 60 месяцев * 480 рублей / месяц = 28 800 рублей.

Итого Сэ = 28 990 рублей.

Учитывая, что Сн составляют 50% от Ср, то

Сн = 0,5*1850 = 925 рублей.

Сs = 1850+28990+925 = 31 765 рублей.

Все результаты сведем в таблицы.

Затраты на разработку ПП

Затраты на эксплуатацию

Общие затраты на создание программного продукта

Мы рассчитали суммарные затраты на разработку данного ПП и увидели, что они составили примерно 32 675 рублей. Наибольшие затраты были на эксплуатацию реализующей ЭВМ.

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