Преподаватель: Ситанов Сергей Вячеславович

Для обеспечения надежности ПС (программного средства) известно 4 подхода:

1. Предупреждение ошибок

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

1. Борьба со сложностью (максимальное упрощение программы)

2. Обеспечение точности перевода

3. Преодоление барьера между пользователем и разработчиком

4. Обеспечение контроля принимаемых решений

Этот подход связан с процессом организации разработки ПС. В рамках этого подхода уже можно достигнуть приемлемого уровня надежности.

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

2. Самообнаружение ошибок

Означает, что программа содержит средства обнаружения отказов.

3. Самоисправление ошибок

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

4. Обеспечение устойчивости к ошибкам

Означает, что влияние ошибки локализовано и не влияет на работоспособность в целом.

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

Например,

Try

… (содержится элемент программы в которой контролируется ошибка)

(если произошла ошибка, то переходит к блоку Catch, где содержатся команды исправления ошибки)

Catch

… (если ошибки нет, то блок Catch игнорируется)

End Catch

Известны два метода «борьбы со сложностью»

1. Обеспечение независимости компонентов системы

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

Типичный пример – использование модульного программирования (известен также как объектно-ориентированный подход). Каждый модуль решает определенный класс задач, используя только собственные внутренние структуры. А связи формируется через стандартизированный интерфейс, независимый от содержания модуля. Благодаря этому каждый модуль может создаваться отдельно от других. И полностью отлаженный модуль в дополнительном контроле не нуждается.

2. Использование иерархических структур

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

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

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

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

1. Поймите задачу

2. Составьте план, включая цели и методы решения

3. Выполните план, проверяя правильность каждого шага

4. Проанализируйте полученное решение

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

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

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

2. Сочетание статических и динамических методов контроля

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

Внешнее описание программного средства

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

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

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

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

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

Во внешнем описании присутствуют две самостоятельные части:

1. Функциональная спецификация ПС – она определяет функции, которые должна выполнять ПС и описывает поведение ПС. Также функциональная спецификация определяет допустимые фрагменты программ, реализующих декларируемые функции.

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

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