Инструментальное обеспечение эксплуатация, и другие процессы инжиниринга ИС

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

1992 ГОСТ 34.601-901995 ISO/IEC 12207:19952000 ГОСТ Р ИСО/МЭК 122072002 ISO/IEC 152882005 ГОСТ Р ИСО/МЭК 15288-20052008 ISO/IEC 12207:20082012 ГОСТ Р ИСО/МЭК 12207-2010ISO – International Organization for Standardization – Международная организация по стандартизацииIEC – International Electrotechnical Commission – Международная комиссия по электротехнике

ГОСТ 34.601-90 "Автоматизированные системы."Стадии создания.

Этапы работ:Обследование объекта и обоснование необходимости создания АСФормирование требований пользователя к АСОформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания).

Этапы работ:Изучение объектаПроведение необходимых научно-исследовательских работРазработка вариантов концепции АС, удовлетворяющего требованиям пользователяОформление отчёта о выполненной работе.

Этапы работ:Разработка и утверждение технического задания на создание АС.

Этапы работ:Разработка предварительных проектных решений по системе и её частямРазработка документации на АС и её части.

Этапы работ:Разработка проектных решений по системе и её частямРазработка документации на АС и её частиРазработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработкуРазработка заданий на проектирование в смежных частях проекта объекта автоматизации.

Этапы работ:Разработка рабочей документации на систему и её частиРазработка или адаптация программ.

Этапы работ:Подготовка объекта автоматизации к вводу АС в действиеПодготовка персоналаКомплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)Строительно-монтажные работыПусконаладочные работыПроведение предварительных испытанийПроведение опытной эксплуатацииПроведение приёмочных испытаний.

Этапы работ:Выполнение работ в соответствии с гарантийными обязательствамиПослегарантийное обслуживание.

ISO/IEC 15288:2005 "Информационная технология. Системная инженерия. Процессы жизненного цикла систем."Стадии создания системы.

Анализ потребностей, выбор концепции и проектных решений.

Проектирование системы.

Изготовление системы

Ввод в эксплуатацию и использование системы.

Обеспечение функционирования системы.

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

ISO/IEC 12207:1995 "Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств."Работы процесса разработки:подготовкаанализ требований к системепроектирование системной архитектурыанализ требований к программным средствампроектирование программной архитектурытехническое проектирование программных средствпрограммирование и тестирование программных средствсборка программных средствквалификационные испытания программных средствсборка системыквалификационные испытания системыввод в действие программных средствобеспечение приёмки программных средств.

ISO/IEC 12207:2008 "Системная и программная инженерия. Процессы жизненного цикла программных средств."Схема описания процессов: Группа процессов Процесс Цели процесса Выходы процесса Виды деятельности процесса (работы) Задачи в пределах деятельности .

Реализация в RUP.Разработка компонент (кодирование)Следование проектной спецификацииCледование правилам процессаРабота с рискамиРегрессионные тестыСвязь с управлениемИнтеграция.Конструирование, согласно SWEBOK.Создание рабочей программной системы посредством комбинацииКодированияВерификации (проверки)Модульного тестирования (unit testing)Тестирования интеграционногоОтладки.

Минимизация сложностиОжидание измененийКонструирование с возможностью проверкиСтандарты в конструировании.

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

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

Конструирование с возможностью проверки (Constructing for Verification).«Конструирование для проверки» предполагает, что построение программных систем должно вестись таким образом, чтобы сама программная система помогала вести поиск причин сбоев, будучи прозрачной для применения различных методов проверки, как на стадии тестирования, так и в процессе эксплуатации.

Стандарты в конструировании (Standards in Constructing):коммуникации (например, форматов документов и оформления содержания)языков программирования и соответствующих стилей кодирования (например, Java Language Specification, являющийся частью стандартной документации JDK – Java Development Kitплатформы (например, стандарты программных интерфейсов для вызовов функций ОС)инструментов (например, UML).

Управление конструированием (Managing Construction)Модели (жизненного цикла) конструирования (Construction Models)Планирование конструирования (Construction Planning)Измерения в конструировании (Construction Measurement)

Практические соображения (Practical Considerations).

Проектирование в конструировании (Construction Design).Некоторые проекты предполагают больший объем работ по проектированию именно на стадии конструирования; другие проекты явно выделяют проектную деятельность в форме проектной фазы.Вне зависимости от этого, на стадии конструирования всегда приходится заниматься и вопросами детального проектирования системы. Отличие заключается в большем внимании деталям.

Языки конструирования (Construction Languages):Конфигурационный языкИнструментальный язык (обычно скрипт)Язык программирования.

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

Тестирование в конструировании (Construction Testing). Модульное тестирование (unit testing)Тестирование интеграции (integration testing).

Повторное использование (Reuse).«Реализация повторного использования программного обеспечения подразумевает и влечёт за собой нечто большее, чем просто создание и использование библиотек активов.Оно требует формализации практики повторного использования на основе интеграции процессов и деятельности по повторному использованию в сам жизненный цикл программного обеспечения».(IEEE Std. 1517-99 “IEEE Standard for Information Technology – Software Lifecycle Process – Reuse Processes”).

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

Качество конструирования (Construction Quality).Модульное и интеграционное тестированиеОпережающее тестированиеИтеративное кодирование с тестированиемИспользование процедур утвержденийОтладкаТехнические обзоры и оценки (review)Статический анализ.

Интеграция (Integration).Интеграция отдельно сконструированных операций (процедур), классов, компонентов и подсистем (модулей)Специальная интеграция с другим программным и аппаратным обеспечениемПланирование последовательности, в которой интегрируются компонентыОбеспечение поддержки промежуточных версийЗадание “глубины” тестированияПланирование вех тестирования интеграции.

Фаза внедрения (Transtion) в RUP.

Подготовка бета-версииУстановка бета-версииПроверка системы (ранняя и финишная)Работа с сообщениями бета-тестеровЗавершение артефактов проектаОпределение факта окончания проекта.

Рыночные продукты и продукты одного клиентаПодготовка площадки для тестированияИнсталляция бета-версииКонвертация данных.

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

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

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

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

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

Методы тестированияUse Cases → Test CasesПриёмосдаточная комиссияПротокол испытанийАкт приемки-сдачиПротокол разногласий.

Документация пользователяДокументация администратораДокументация программиста.

Общие подходыОбучение в условиях бета-версииАттестация как метод мотивации.

Тестирование программных систем состоит из динамической верификации поведения программ на конечном (ограниченном) наборе тестов (set of test cases), выбранных соответствующим образом из обычно выполняемых действий прикладной области и обеспечивающих проверку соответствия ожидаемому поведению системы.

Тестирование в узком смысле, иначе – динамическое тестирование, предполагает выполнение кода программы (программного продукта)Тестирование программного обеспечения (в широком смысле) – процесс анализа или эксплуатации программного обеспечения с целью выделения дефектов, также часто называют верификацией; оно включает и другие методы (например, просмотр программного кода). (Test Object, Test Case, Test Plan, Test, Regression Test).Верификация – проверка продукта на соответствие входным данным (~ проектным требованиям, спецификациям) (ИСО 9000/2000).Валидация – проверка продукта на соответствие потребностям пользователя (ИСО 9000/2000).Дефект – изъян в работе программного обеспечения, приводящий к несоответствию фактических результатов функционирования программного обеспечения ожидаемым (defect, bug, failure, fault, error).

Критерии отбора тестов нужны:для создания набора тестовдля проверки, насколько выбранные тесты адекватны решаемым задачам (тестирования)При этом, они помогают определить, когда можно или необходимо прекратить тестирование.Основной вопрос тестирования: "Сколько нужно тестировать?"Тестирование следует продолжать до тех пор, пока затраты на обнаружение и исправление дефектов НИЖЕ, чем будущие потери от сбоев продукта при его эксплуатации.

Эффективность теста может быть определена только в контексте заданных условий.

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

“Оракул”, в данном контексте, любой агент (человек или программа), оценивающий поведение программы, формулируя вердикт - тест пройден (“pass”) или нет (“fail”).«Проблема оракула» - формулировка критериев успешности прохождения тестов, одна из основных проблем тестирования.

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

Теория тестирования выступает против необоснованного уровня доверия к серии успешно пройденных тестов.К сожалению, большинство установленных результатов теории тестирования – негативны, означая, по словам Дейкстры (Dijkstra), то, что “тестирование программы может использоваться для демонстрации наличия дефектов, но никогда не покажет их отсутствие”.Основная причина этого в том, что полное (всеобъемлющее) тестирование недостижимо для реального программного обеспечения.

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

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

Позволяет проверить функционирование отдельно взятого элемента системыЧто считать элементом – модулем системы, определяется контекстомНаиболее полно данный вид тестов описан в стандарте IEEE 1008-87 “Standard for Software Unit Testing”, задающем концепцию систематического и документированного подхода к модульному тестированию.

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

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

Общепринятое определение:Цель тестирования – снизить неопределённость нашего представления о качестве программного продукта.Более широкое определение:Цель тестирования – распознать дефекты в объекте тестирования и увеличить вероятность того, что он при любых обстоятельствах будет работать надлежащим образом в соответствии с установленными требованиями.Роль тестирования состоит в получении объективной информации, способствующей принятию более качественных деловых решений.Роль тестирования - держать в курсе всех проблем, имеющих отношение к поставке продукта.

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

 Данные тесты проводятся с целью проверки процедуры инсталляции системы в целевом окружении.

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

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

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

Определение успешности регрессионных тестов (IEEE 610-90 “Standard Glossary of Software Engineering Terminology”) : “повторное выборочное тестирование системы или компонент для проверки сделанных модификаций не должно приводить к непредусмотренным эффектам”. На практике это означает, что если система успешно проходила тесты до внесения модификаций, она должна их проходит и после внесения таковых. 

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

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

Единичный набор тестов, позволяющих сравнить две версии системы.

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

В случаях, если программное обеспечение создается для использования различными пользователями (в терминах “ролей”), данный вид тестирования направлен на проверку поведения и работоспособности системы в различных конфигурациях.

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

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

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

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

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

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

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

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

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

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

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

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

Является не столько техникой тестирования, сколько контролем структуры программы, представленной в виде дерева вызовов (например, sequence-диаграммы, определенной в нотации UML и построенной на основе анализа кода).

Как это ни странно звучит на уровне названия таких техник тестирования, они, действительно, ориентированы на ошибки. Точнее – на специфические категории ошибок.

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

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

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

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

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

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

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

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

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

Создание тестовых сценариев основывается на уровне и конкретных техниках тестирования. Тесты должны находиться под управлением системы конфигурационного управления и описывать ожидаемые результаты тестирования.

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

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

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

Во многих случаях, в процессе тестовой деятельности ведётся журнал тестирования, фиксирующий информацию о соответствующих работах: когда проводится тест, какой тест, кем проводится, для какой конфигурации программной системы (в терминах параметров и в терминах идентифицируемой версии контекста конфигурационного управления) и т.п. Неожиданные или некорректные результаты тестов могут записываться в специальной подсистеме ведения отчетности по сбоям (problem-reporting system, обеспечивая формирование базы данных, используемой для отладки, устранения проблем и дальнейшего тестирования. Кроме того, аномалии (помехи), которые нельзя идентифицировать как сбои, также могут фиксироваться в журнале и/или системе ведения отчетности по сбоям. В любом случае, документирование таких аномалий снижает риски процесса тестирования и помогает решать вопросы повышения надежности самой тестируемой системы. Отчёты по тестам могут являться входом для процесса управления изменениями и генерации запросов на изменения (change request) в рамках процессов конфигурационного управления (см. далее соответствующую область знаний “Software Configuration Management”).

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

СОПРОВОЖДЕНИЕ (ISO IEC 12207)Процесс сопровождения реализуется оператором сопровожденияПроцесс инициируется при возникновении проблем, возникших при эксплуатации системы, либо потребностей в модернизации системы или переносе её на другую платформуЦель процесса – изменение существующего программного продукта при сохранении его целостности; заканчивается он снятием системы с эксплуатации.

Фиксируются и отслеживаются запросы на изменения” – change requestsОценивается влияние предлагаемых измененийМодифицируется код и другие артефактыПроводится необходимое тестированиеВыпускается обновленная версия продуктаПроводится обучение пользователейОбеспечивается ежедневная поддержка пользователей при работе с текущей версией продукта.

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

ПРОЦЕДУРЫ УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ (К.ВИГЕРС) базируются на:Инструментах, приемах и соглашениях по управлению версиями различных документов требований и отдельных требованийПравилах составления базовой версии требованийСтатусах требований, которые будут использоваться, и категориях лиц, которые имеют право изменять ихПроцедурах контроля за статусом требованияСпособах, с помощью которых новые требования и изменения существующих требований предлагаются, обрабатываются, обсуждаются и передаются совладельцамМетодах анализа влияния предложенного измененияОтслеживании связей планов и обязательств проекта с изменением требований. 

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

КОНФИГУРАЦИЯ — внешнее очертание, а также взаимное расположение предметов или их частей. (Толковый словарь Ожегова)КОНФИГУРАЦИЯ (CONFIGURATION) — Функциональные, физические и эксплуатационные свойства (характеристики) предполагаемого к разработке, разрабатываемого или существующего изделия, сгруппированные в соответствии с его структурой и отображаемые в различных формах документации в зависимости от стадии ЖЦ этого изделия.

ЗАДАЧИ SCM (SOFTWARE CONFIGURATION MANAGEMENT):Определение объектов (идентификация конфигурации) и помещение их в защищённое хранилищеКонтроль изменений объектовПравила изменений. Аудит (автор, дата, цель)Объединение объектов в подсистемыУчёт версий на основных этапах проектаВоспроизводимость. Контролируемость. Ведение отчётовРегистрация и отслеживание запросов на изменениеФормирование и объединение пакетов изменений, связанных с решением задачСвязь между версиями и причинами их возникновенияПоддержание целостного и стабильного рабочего пространстваВозможность параллельных измененийРанние и частые интеграцииВоспроизводимость сборок программ (автор сборки, компьютер, последовательность, операционная система) .

ИНСТРУМЕНТЫ РАБОТЫ С ТРЕБОВАНИЯМИ (SOFTWARE REQUIREMENTS TOOLS)Средства моделированияСредства трассировки

ИНСТРУМЕНТЫ ПРОЕКТИРОВАНИЯ (SOFTWARE DESIGN TOOLS)

ИНСТРУМЕНТЫ КОНСТРУИРОВАНИЯ (SOFTWARE CONSTRUCTION TOOLS)РедакторыКомпиляторы и генераторы кодаИнтерпретаторыОтладчики… Интегрированные средства разработки (IDE).

ИНСТРУМЕНТЫ ТЕСТИРОВАНИЯ (SOFTWARE TESTING TOOLS)Генераторы тестовСредства исполнения тестовИнструменты оценки (результатов) тестовСредства управления тестамиИнструменты анализа производительности.

ИНСТРУМЕНТЫ СОПРОВОЖДЕНИЯ (SOFTWARE MAINTENANCE TOOLS)Инструменты облегчения понимания (comprehension tools) (например, визуализация)Инструменты реинжиниринга (reengineering tools). (например, обратный инжиниринг).

ИНСТРУМЕНТЫ КОНФИГУРАЦИОННОГО УПРАВЛЕНИЯ (SOFTWARE CONFIGURATION MANAGEMENT TOOLS)Инструменты отслеживания (tracking) дефектов, расширений и проблемИнструменты управления версиямиИнструменты сборки и выпускаПредназначены для управления задачами сборки и выпуска продуктов, а также включают средства инсталляции.

ИНСТРУМЕНТЫ УПРАВЛЕНИЯ ИНЖЕНЕРНОЙ ДЕЯТЕЛЬНОСТЬЮ (SOFTWARE ENGINEERING MANAGEMENT TOOLS)Инструменты планирования и отслеживания проектовИнструменты управления рисками. (идентификация, оценка ожиданий и мониторинг рисков)Инструменты количественной оценки.

ИНСТРУМЕНТЫ ПОДДЕРЖКИ ПРОЦЕССОВ (SOFTWARE ENGINEERING PROCESS TOOLS)

ИНСТРУМЕНТЫ ОБЕСПЕЧЕНИЯ КАЧЕСТВА (SOFTWARE QUALITY TOOLS)Инструменты инспектирования. (поддержки обзора (review) и аудита)Инструменты (статического) анализа. Используются для анализа программных артефактов, данных, потоков работ и зависимостей.

ОСНОВНЫЕ СТАНДАРТЫ КАЧЕСТВА, ПРИМЕНЯЕМЫЕ В IT-ИНДУСТРИИ:ISO9000ISO/IEC 15504 (SPICE)SEI CMMSEI CMMIBootstrapTickIT

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

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

Результат непредсказуем; процесс ad hocРезультат предсказуем; есть управление процессомТехнология разработки и управление определены и согласованно объединеныПроцесс и его продукты контролируются и управляются постоянными измерениямиВстроенное совершенствование процесса.