ПОЗНАВАТЕЛЬНОЕ

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

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

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

Лекция 3. Верификация, тестирование и оценивание корректности программных компонентов

1 234 5

План лекции:

1. Задачи верификации в рамках жизненного цикла ПО

2. Верификация и другие процессы разработки и сопровождения ПО

3. Верификация различных артефактов жизненного цикла ПО

4. Методы верификации программного обеспечения

Задачи верификации в рамках жизненного цикла ПО

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

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

· Выявление наиболее критичных и наиболее подверженных ошибкам частей создаваемой или сопровождаемой системы.

· Контроль и оценка качества ПО во всех его аспектах.

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

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

Верификация и другие процессы разработки и сопровождения ПО

Процессом жизненного цикла ПО называется группа видов деятельности, выполняемых для решения определенного набора связанных задач по разработке или сопровождению ПО. Международные стандарты ISO 12207 [15], IEEE 1074 [28], ISO 15288 [29], ISO 15504 [30] используют несколько отличающиеся системы процессов.

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

Верификация различных артефактов жизненного цикла ПО

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

Методы верификации программного обеспечения

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

Экспертиза (review) различных артефактов жизненного цикла ПО. Обычно в качестве видов экспертиз выделяют организационные экспертизы (management review), технические экспертизы (technical review), сквозной контроль (walkthrough), инспекции (inspection) и аудиты (audit). С середины 1990-х активно развиваются методы оценки архитектуры ПО на основе сценариев (scenario based software architecture evaluation), обычно не соотносимые с «традиционными» экспертизами. От других методов верификации экспертизу отличает возможность выполнять ее, используя только сами артефакты жизненного цикла, а не их модели (как в формальных методах) или результаты работы (как в динамических).

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

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

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

Синтетические методы. В последние 10-15 лет появилось множество исследовательских работ и инструментов, в рамках которых применяются элементы нескольких перечисленных выше видов верификации. Так, в отдельные области выделились динамические методы, использующие элементы формальных, — тестирование на основе моделей (model-based testing, model driven testing) [73] и мониторинг формальных свойств (runtime verification, passive testing). Ряд инструментов построения тестов существенно использует как формализацию некоторых свойств ПО, так и статический анализ кода. Общая идея таких методов вполне понятна — попытаться сочетать преимущества основных подходов к верификации, купировав их недостатки.

Лекция 4. Формальные инспекции. Задачи и цели проведения формальных инспекций. Этапы формальной инспекции и роли ее участников Формальные инспекции программного кода Формальные инспекции проектной документации

План лекции:

1. Задачи и цели проведения формальных инспекций

2. Этапы формальной инспекции и роли ее участников

3. Документирование процесса формальной инспекции

4. Формальные инспекции программного кода

Задачи и цели проведения формальных инспекций

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

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

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

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

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

Этапы формальной инспекции и роли ее участников

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

1. Инициализация

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

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

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

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

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

2. Планирование

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

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

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

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

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

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

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

3. Подготовка

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

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

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

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

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

4. Обсуждение

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

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

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

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

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

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

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

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

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

Отметка в графе "N/A" ("Неприменимо") ставится только в том случае, когда сформулированное в соответствующем вопросе свойство не может быть оценено для данного объекта инспекции; в этом случае в графе "Замечания" записывается обоснование невозможности оценить данное свойство.

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

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

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

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

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

5. Завершение

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

После собрания ведущий изменяет статус инспектируемых документов в базе данных проекта в соответствии с принятым решением - либо им присваивается статус "Принят", либо "Переработать".

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

Документирование процесса формальной инспекции

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

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

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

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

1. Бланк инспекции

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

Бланк инспекции состоит из трех основных частей:

титульный лист;
список контрольных вопросов;
список несоответствий.

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

Формальные инспекции программного кода

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

1. Особенности этапа просмотра инспектируемого кода

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

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

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

3. Особенности этапа завершения и повторной инспекции

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

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

Формальные инспекции проектной документации

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

Особенности этапа просмотра документации

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

1. Является ли каждое требование совершенно недвусмысленным? (Если требование прочесть подряд несколько раз, делая ударение сначала на первом слове, потом - на втором, затем - на третьем и т.д., будет ли при этом меняться смысл этого требования?)

2. Существует ли для каждого из установленных требований некоторый компетентный специалист, который сможет сказать после завершения разработки, выполнено ли данное требование или нет? Определен ли метод решения этой проблемы в документации по требованиям?

3. Существует ли какие-либо не установленные или отсутствующие требования?

4. Существуют ли среди заданных такие требования, которые не являются необходимыми?

5. Если существуют какие-либо конфликтующие требования, известно ли понятное решающее правило, в каких ситуациях какому требованию следует отдавать предпочтение?

Особенности этапа завершения

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

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

1 234 5