РиСтПСиИТ 

 

Оглавление

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

3. Фазы жизненного цикла программы.. 3

4. Процессы жизненного цикла программных средств. 4

5. Стандартизация открытых систем. Эталонная модель открытых систем. 6

6. Тестирование программных средств. Способы тестирования. 7

7. Тестирование модулей. 8

 

 

 

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

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

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

Мобильность - программа является завершенной и машинонезависимой.

Модифицируемость - это возм-ть расширения вычислительных возможностей отдельных модулей.

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

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

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

1)  нарушение разработчиком программы спецификации - технических требований к программе;

2)  спецификация неточная или не полная.

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

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

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

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

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

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

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

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

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

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

2. Cтандартизация жизненного цикла программы. Модели жизненного цикла

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

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

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

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

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

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

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

Кубическая модель ЖЦ позволяет рассматривать разработку программы в 3 измерениях: этапы разработки, компоненты программной системы и содержание работ по разработке данного компонента на данном этапе. Модель предполагает, что каждый   из компонентов программной системы разрабатывается по своему технологическому циклу. Разрешается выполнять любой из этапов разработки любого компонента, если для этого достаточно проектной информации и ресурсов. Проект системы формируется путем постепенного заполнения свободных мест («кубиков») кубической модели в порядке, определяемом проектировщиками по обстоятельствам. Управление разработкой по кубической модели сводится к планированию срока завершения всего проекта, определению структуры проекта по этапам и компонентам, расчету трудозатрат проекта по этапам каждого компонента, а также к контролю заполнения проекта решениями. Кубическая модель разработки предназначена, прежде всего, для использования в CASE – системах автоматизации разработки программных средств, являясь основой для построения базы данных проекта и контроля полноты проекта.

 

 

 

3. Фазы жизненного цикла программы

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

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

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

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

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

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

 

4. Процессы жизненного цикла программных средств

В 1999 г. он введен в России и странах СНГ—ГОСТ Р ИСО/МЭК 12207:99.

ISO12207 — базовый стандарт процессов ЖЦ ПО, ориентированный на различные виды ПО и типы проектов АС, куда ПО входит как часть. Стандарт определяет стратеги j и общий поря­док в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концепту­ализации идей до завершения ЖЦ.

Стандарт не предписывает конкретную модель ЖЦ или метод разра­ботки ПО, но определяет, что стороны — участники использования стан­дарта ответственны за выбор модели ЖЦ для проекта ПО, за адаптацию процессов и задач стандарта к этой модели, за выбор и применение мето­дов разработки ПО, за выполнение действий и задач, подходящих для проекта ПО.

В стандарте ISO 12207 описаны:

1) пять основных процессов ЖЦ ПО:

•    процесс приобретения. Определяет действия предприятия-покупателя, которое приобретает АС, программный продукт или сервис ПО;

•    процесс поставки. Определяет действия предприятия-поставщика, снабжающего покупателя системой, программным продуктом или сервисом ПО;

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

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

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

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

- Процесс документирования. Включает форматированное описание информации, созданной в течении ЖЦ системы.

- Процесс управления конфигурацией. Предполагает применение административных и технических процедур на всем протяжении ЖЦ ПС для определения состояния компонентов системы, для управления модификациями ПС, подготовки и описания отчетов, для управления хранением и поставкой ПС (программного средства).

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

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

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

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

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

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

3) четыре организационных процесса: управления; создания инфраструктуры; усовершенствования; обучения.

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

Под процессом усовершенствования здесь понимается не усовершенствование АС или ПО, а улучшение самих процессов приобретения, раз­работки, гарантирования качества и т.п., реально осуществляемых в орга­низации.

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

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

 

5. Стандартизация открытых систем. Эталонная модель открытых систем.

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

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

Для облегчения  взаимопонимания  между  указанными выше  группами специалистов целесообразно использовать единую модель среды открытых систем. Такой моделью служит так называемая эталонная модель среды открытых систем  (Open System Environment Reference Model - OSE/RM ) (Рис ).

Как видно из рисунка эталонная модель является трехмерной. По вертикали в ней можно выделить следующие компоненты: приложение; платформу; внешнюю среду; интерфейс приложения с платформой; интерфейс платформы с внешней средой

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

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

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

 

6. Тестирование программных средств. Способы тестирования.

Тестирование (testing) —процесс выполнения программы с намерением (или целью) найти ошибки.

Доказательство (proof) — попытка найти ошибки в програм­ме безотносительно к внешней для программы среде.

Контроль (verification) - попытка н-ти ошибки, выполняя программу в тестовой, моделируемой, среде.

Испытание (validation) — попытка найти ошибки, выполняя программу в заданной реальной среде.

Аттестация (certification) — авторитетное подтверждение правильности программы. При тестировании с целью аттеста­ции выполняется сравнение с некоторым заранее определенным стандартом.

Отладка (debugging) направлена на установление точной при­роды известной ошибки, а затем - на исправление этой ошибки. Эти два вида деятельности связаны – результаты тестирования являются исходными данными для отладки.

Тестирование модуля, или автономное тестирование (module testing, unit testing), — контроль отдельного программного моду­ля, обычно в изолированной среде (т. е. изолированно от всех остальных модулей). Тестирование модуля иногда включает так­же математическое доказательство.

Тестирование сопряжений (integration testing) — контроль со­пряжений между частями системы (модулями, компонентами, под­системами).

Тестирование внешних функций (external function testing) — контроль внешнего поведения системы, определенного внешни­ми спецификациями.

Комплексное тестирование (system testing) — контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выпол­няется в моделируемой среде, и процессом испытания, если вы­полняется в среде реальной, жизненной.

Тестирование приемлемости (acceptance testing) — проверка соответствия программы требованиям пользователя.

Тестирование настройки (installation testing) — проверка со­ответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы.

Тестирование программы как «черного ящика»

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

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

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

Тестирование программы как «белого ящика»

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

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

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

 

 

7. Тестирование модулей

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

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

1.  Монолитное тестирование требует больших затрат труда. При пошаговом же тестировании «снизу-вверх» затраты труда сокращаются.

2.  Расход машинного времени при монолитном тестировании меньше.

3.  Использование монолитного метода предоставляет боль­шие возможности для параллельной организации работы на на­чальной фазе тестирования (тестирования всех модулей одновре­менно).

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

5. Отладка программ при пошаговом тестировании легче.

6.  Результаты пошагового тестирования более совершенны.

п. 1, 4, 5, 6 демонстрируют пре­имущества пошагового тестирования (выходят на первый план), а п. 2 и 3 — его недостат­ки, след-но, пошаговое тести­рование является предпочтительным.

Восходящее тестирование

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

Нисходящее тестирование

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

Метод «большого скачка» самый распространенный подход к интеграции модулей. В соответствии с этим ме­тодом каждый модуль тестир-ся автономно. По окончании те­стир-я модулей они интегрир-ся в систему все сразу. Заглушки и драй­веры необх. для каждого модуля. Метод приемлем для малых прог.

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

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

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

Модифицированный метод сандвича

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