Калайда В.Т., Романенко В.В. Технология разработки программного обеспечения, страница 3

2.3 — Схема проектирования программных системПрежде всего Заказчик анализирует и формулирует требования реальности, которые находят отображение в требованиях, предъявляемых к программной системе. Однако ЭВМ неспособна решить задачу непосредственно, реальные данныенеобходимо каким-то образом закодировать и ввести в ЭВМ.Подобная модель решаемой задачи представляет собой абстрактное выражение реального мира и отражается в спецификациях.Если спецификации программы определены, возникаетнеобходимость в описании процесса обработки информации,что относится к этапу проектирования. Поскольку программадолжна использоваться для реальной задачи, то на этапе реализации проекта (кодирование, тестирование) осуществляетсяперевод формального проекта в выполняемую программу.И наконец, пользователь может сравнить планируемуюфункцию программы с реализованной функцией.

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

2.4).14УправляющаяпрограммаСинтаксическийанализаторБлок сканированияГенератор кодаПрограмма таблицысимволаВывод на печатьЧтениеРис. 2.4 — Структурная схема компилятораТакая схема называется базисной, и она не адекватна спецификациям. Поскольку в начале этапа проектирования решение ряда функциональных задач зачастую не определено, процесс разбиения на подзадачи может быть весьма сложным. Впроектировании программных систем обычной является ситуация, когда Заказчик не знает, что точно он хочет.

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

По имеющимся статистическимданным 64 % всех ошибок вносятся на этапах проектирования илишь 36 % на этапе кодирования. Однако эти ошибки могутбыть очень дорогостоящими (DO 4 I=1,5 и DO 4 I=1.5). Вобщем случае кодирование освоено лучше, чем другие этапысоздания программ, и очень четко формализовано.152.5 ТестированиеЭтап тестирования обычно в финансовых затратах составляет половину расходов на создание системы. Плохо спланированное тестирование приводит к существенному увеличениюсроков разработки системы и является основной причиной срывов графиков разработки.В процессе тестирования используются данные, характерные для системы в рабочем состоянии, т.е. данные для тестирования выбираются случайным образом.

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

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

Исправление этих ошибок может составлять до ¼ от общих затрат.Системное (или оценочное) тестирование — это завершающая стадия проверки системы, т.е. проверка системы в целомс помощью независимых тестов. Независимость тестов являетсяглавным требованием. Обычно Заказчик на стадии приемки работ настаивает на проведении собственного системного тестирования. Для случая, когда сравниваются характеристикинескольких систем (имеется альтернативная разработка), такаяпроцедура известна как сравнительное тестирование.16В процессе тестирования, для определения правильностивыполнения программы вводится ряд критериев:1) каждый оператор должен быть выполнен, по крайнеймере, один раз для заданного набора тестов, и программа должна выдать правильный результат;2) каждая ветвь программы должна быть опробована, ипрограмма при этом должна выдать правильный результат;3) каждый путь в программе должен быть испытан хотя быодин раз с использованием набора тестовых данных, ипрограмма должна выдать правильный результат;4) для каждой спецификации программы необходимо располагать набором тестовых данных, позволяющихустановить, что программа правильно реализует данную спецификацию.Хотя критерии 1) и 2) кажутся схожими, в действительности они сильно разнятся.

Например, арифметический операторIF в Fortran:IF (Выражение) N1, N2, N3.Критерий 1) подразумевает, что IF должен быть выполнен, в то время как 2) подразумевает различные наборы данных,для того чтобы выполнились условия N1, N2, N3 (т.е. передачуна эти метки).В общем случае не существует единого программногокритерия, определяющего «хорошо проверенную» программу.Тесно связаны с тестированием понятия «верификация» и«испытание».Испытание системы осуществляется посредством тестирования.

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

Исправление выброса можно предусмотреть в программе, так что не каждый выброс может приводить к сбою.Ошибка — это алгоритмический дефект, который создаетвыброс (программная ошибка).Различают понятия «правильная» и «надежная» программа. Правильная программа — это та, что удовлетворяет своимспецификациям. Что касается надежной программы, то она необязательно является правильной, но выдает приемлемый результат даже в том случае, когда входные данные либо условияее использования не удовлетворяют принятым допущениям.Естественно стремление иметь «живую» (robustness) систему,т.е.

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

2.5):181)2)3)4)5)6)7)анализ требований;определение спецификаций;проектирование;кодирование;автономное тестирование;комплексное тестирование;сопровождение.Определение спецификаций (3%)Анализ требований (3%)Проектирование (5%)Кодирование (7%)Автономноетестирование(8%)Сопровождение(67%)Комплексноетестирование (7%)Рис. 2.5 — Временные затраты на реализацию этапов жизненного цикла программного обеспеченияНи одна из вычислительных систем не остается неизменной по мере ее эксплуатации. Это объясняется несколькимипричинами, среди которых можно выделить следующие:1. Заказчик обычно не может четко сформулировать своитребования, редко бывает удовлетворен созданной системой и поэтому настаивает на внесении изменений вготовую систему.2.

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

Хотя написаниекодов и создает иллюзию благополучия у руководителя проекта, однако это чревато такими последствиями, как многократноетестирование и возникновение большого числа проблем на более позднем этапе сопровождения.Задачу сопровождения обычно трактуют как задачу отработки непомерно возрастающего числа версий системы.Пусть некоторая система содержит компоненты A, B, C иустановлена у потребителей I, II, III (рис.

2.6).ABCABCABCIIIIIIРис. 2.6 — Исходные системы потребителейВ процессе эксплуатации системы потребитель I обнаружил ошибку и сообщил об этом разработчику. Последний корректирует ее и направляет исправленный модуль A’ всем пользователям системы. Опыт применения надежного программногообеспечения показывает, что большинство потребителей ведетсебя осторожно в отношении внесенных изменений. Поэтомупотребители II и III, не встречаясь с задачами, решаемыми потребителем I, продолжают использовать первоначальный вариант системы, поддерживая принцип «если система работает, невмешивайся».

Спустя некоторое время потребители I и II обнаружили другую ошибку в модуле A. Разработчик должен определить, являются ли обе обнаруженные ошибки одной и той же,поскольку использовались различные версии модуля A. Исправ-20ление ошибки ведет к корректировке модуля A и A’, в результате чего в эксплуатацию вводятся модули A’’ и A’’’. Теперьфункционируют уже три версии системы (рис. 2.7).A’’BCA’’’BCABCIIIIIIРис.

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