maran program engineering (Маран Программная инженерия), страница 4

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

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

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

Поставка и внедрениеПоставка — это передача разработанного программного продукта от разработчика заказчику для внедрения. Внедрение — это по существу процесс отчуждения разработки от автора. По завершении внедрения программный продукт должен работать у заказчика без постоянного участия разработчика. Внедрение состоит из двух этапов:15• опытная эксплуатация;• промышленная эксплуатация.В ходе опытной эксплуатации разработчик и заказчик работают вместе.Разработчик должен помогать освоить работу с новым программным продуктом, а заказчик освоить работу. Разработчик должен устранить выявленные входе опытной эксплуатации ошибки и недочёты (никому еще не удалось создать программный продукт без единой ошибки!), еще раз проверить работоспособность своей разработки в реальных условиях.Опытная эксплуатация постепенно переходит в промышленную эксплуатацию, когда программный продукт работает в реальных условиях эксплуатации (объем базы данных, количество одновременно работающих пользователей, быстродействие в наихудших условиях и т.

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

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

Корректирующее сопровождение. Реактивное изменение программногопродукта, выполняемое после его поставки для корректировки обнаруженных проблем.3. Экстренное сопровождение. Незапланированная модификация, выполняемая для временного сохранения работоспособности программногосредства, ожидающего корректирующее сопровождение.4. Сопровождаемая модификация. Изменения к существующему программному продукту для удовлетворения новых требованиий.5. Предложение к модификации.

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

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

Валидация в контексте жизненного цикла представляет собой совокупность действий, гарантирующих и обеспечивающих уверенность в том, что система способна реализовать свое предназначение, текущие и перспективные цели.Верификация (verification): подтверждение (на основе представленияобъективных свидетельств) того, что заданные требования полностью выполнены. Верификация в контексте жизненного цикла представляет собой совокупность действий по сравнению полученного результата жизненного цикла стребуемыми характеристиками для этого результата.В дальнейшем будут рассмотрены стадии анализа, проектирования, программирования, тестирования и отладки. Содержание названных стадий будетразъяснено по ходу изложения.Рассмотрим каскадную модель жизненного цикла и модель «спираль».Каскадная модель (под влиянием английского языка именуемая иногда «водопад» — Waterfall) представлена на рис.

1.1.Характерная черта этой модели — полное завершение предыдущего этападо начала следующего, другими словами, полное отсутствие обратных связей.В связи с этим имеются следующие ограничения:1. Эта модель предполагает, что требования к разрабатываемой системе заморожены до начала проектирования.2. Замораживание требований к системе обычно влечет за собой и выбортехнических средств в начале разработки (они являются частью требований к системе).17АнализПроектированиеРеализацияТестированиеСборкаВнедрениеСопровождениеРис. 1.1При разработке нового программного средства трудно это обеспечить.Поэтому, согласно этой модели, можно организовать, главным образом, разработку простых систем или новых версий уже внедренных систем.

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

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

1.219Обеспечить аддитивность сразу с первой версии на практике часто затруднительно, тем более что первые 1–2 версии могут быть прототипами: ихневозможно еще внедрить, они служат для лучшего взаимопонимания заказчика и разработчика, для уточнения постановки задачи, а также для проработкипринципов реализации, особенно сложных компонентов.Успех разработки по модели «спираль» во многом зависит от правильного определения очередности решаемых задач. Действует известный изстроительства принцип: от фундамента к крыше, но не наоборот.

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

При положительном решении будет поставлена задача разработки 1-й версии. От 1 до 2будут выполнены все этапы жизненного цикла, но только для этой версии.В точке 2 подводятся итоги выполнения 1-й версии: что получилось, что нет, ипринято решение: продолжать работу или нет. И так, версия за версией, будетразработано все программное средство. В точке n будет принято решение, чтодальнейшая работа над этим программным средством нецелесообразна, надоприступить к разработке нового. В точке n+1 разработчик прекращает сопровождение.Преимущества этой модели:• объем работы при разработке одной версии меньше, поэтому работу легче организовать и управлять ею;• опыт разработки предыдущих версий будет учтен при работе над следующими;• в случае неудачи материальные потери будут меньше;• разработанные версии могут быть внедрены, и заказчик получит реальную пользу.20Powered by TCPDF (www.tcpdf.org)2.

Методологии разработкипрограммного обеспечения2.1. Классические методологии2.1.1. Метод функциональной декомпозицииИсторически первой методикой разработки программного обеспечениябыл метод функциональной декомпозиции. Метод и сегодня может успешноприменяться при решении алгоритмически сложных задач, не связанных с обработкой больших массивов данных. Сюда относятся многие инженерные и научные задачи. Постановка задачи традиционная: Дано: исходные данные. Найти: требуемый результат. Могут быть добавлены дополнительные условия.