Билет 3

1. +Стадии жизненного цикла программного обеспечения

В состав жизненного цикла ПО обычно включаются следующие стадии:

1. Формирование требований к ПО.

2. Проектирование.

3. Реализация.

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

5. Ввод в действие.

6. Эксплуатация и сопровождение.

7. Снятие с эксплуатации.

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

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

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

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

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

• модели "ТО-ВЕ" ("как должно быть"), отражающей представление о новых технологиях работы организации.

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

Переход от модели "AS-IS" к модели "ТО-ВЕ" может выполняться двумя способами:

1. совершенствованием существующих Технологий на основе оценки их эффективности;

2. радикальным изменением технологий и перепроектированием бизнес-процессов (реинжиниринг бизнес-процессов).

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

Стадия проектирования. Она, как правило, включает следующие этапы:

• разработка системного проекта. На этом этапе дается ответ на вопрос: "Что должна делать будущая система?", а именно: определяются архитектура системы, ее функции, внешние условия функционирования, интерфейсы и распределение функций между пользователями и системой, требования к программным и информационным компонентам, состав исполнителей и сроки разработки. Основу системного проекта составляют модели проектируемой ЭИС, которые строятся на основе модели "ТО-ВЕ". Документальным результатом этапа является техническое задание;

• разработка технического проекта. На этом этапе на основе системного проекта осуществляется собственно проектирование системы, включающее проектирование архитектуры системы и детальное проектирование. Таким образом, дается ответ на вопрос: "Как построить систему, чтобы она удовлетворяла предъявленным к ней требованиям?". Модели проектируемой ЭИС при этом уточняются и детализируются до необходимого уровня.

Содержание последующих стадий совпадает в основном с соответствующими процессами ЖЦ ПО.

2. -Принцип модульного построения программ

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

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

Надежность программ.

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

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

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

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

Здесь также следует учесть, что в вычислительных системах сбои (не смотря на аппаратные противосбойные мероприятия, такие как введение проверок на четность, кодов Хемминга), появляются на порядок чаще, чем устойчивые отказы. Для оценки показателей надежности по отношению к сбоям могут применяться такие же оценки, как и по отношению к устойчивым отказам. Наиболее часто используются: вероятность бессбойной работы (вероятность того, что в заданном интервале времени t будут отсутствовать сбои ЭВМ), средняя наработка на сбой (отношение наработки восстанавливаемого объекта к математическому ожиданию числа его сбоев в течение этой наработки).

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

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

• контроля данных, поступающих из внешней среды и

• средств обнаружения аномалий функционирования ПС.

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

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

Длительность восстановления – этот критерий учитывает возможность многократных отказов и восстановлений.

Коэффициент готовности отражает вероятность иметь восстанавливаемую систему в работоспособном состоянии в произвольный момент времени.

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

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