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

7.2.3. Функциональное тестирование

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

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

В задачи функционального тестирования входят:

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

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

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

Предпосылки функционального тестирования:

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

7.3. Инфраструктура процесса тестирования ПС

Под инфраструктурой процесса тестирования понимается:

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

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

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

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

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

7.3.1. Методы поиска ошибок в программах

Международный стандарт ANSI/IEEE-729-83 разделяет все ошибки в разработке программ на следующие типы.

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

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

Отказ (failure) — это отклонение программы от функционирования или невозможность программы выполнять функции, определенные требованиями и ограничениями, что рассматривается как событие, способствующее переходу программы в неработоспособное состояние из-за ошибок, скрытых в ней дефектов или сбоев в среде функционирования [7.6, 7.11]. Отказ может быть результатом следующих причин:

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

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

Ошибки на этапах процесса тестирования.Приведенные типы ошибок распределяются по этапам ЖЦ и им соответствуют такие источники их возникновения [7.12]:

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

Рассмотрим процесс тестирования, исходя из рекомендаций стандарта ISO/IEC 12207, и приведем типы ошибок, которые обнаруживаются на каждом процессе ЖЦ.

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

Характерными ошибками этого процесса являются:

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

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

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

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

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

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

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

Все ошибки, которые возникают в программах, принято подразделять на следующие классы [7.12]:

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

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

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

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

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

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

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

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

На современном этапе развития средств поддержки разработки ПО (CASE-технологии, объектно-ориентированные методы и средства проектирования моделей и программ) проводится такое проектирование, при котором ПО защищается от наиболее типичных ошибок и тем самым предотвращается появление программных дефектов.

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

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

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

Приведем следующую классификацию типов отказов:

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

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

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

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

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

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

Автор статьи: Дмитрий Курдюмов

Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом.

Все мы с вами так или иначе сталкиваемся с требованиями, когда мы что-то от кого-то хотим, когда кому-то что-то объясняем. И так или иначе, когда мы с вами доносим определенные требования, наша цель — передать полную картину, чтобы наш запрос был выполнен.

В разработке программного обеспечения или продуктов существует разные типы требований:

  • функциональные

  • нефункциональные

  • пользовательские

  • бизнес-требования

и много других.

Фокус требований в Agile

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

Почему? Потому что наши продукты в итоге будут покупать пользователи. 

(!) Но это не значит, что мы должны слепо спрашивать их, что им нужно. Вместо этого мы должны изучать их потребности и поведение.

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

Первая ошибка — идти от конкретных решений, а не от потребностей пользователей

То есть закладывать в требование сразу сформулированное решение.

Например, часто заказчики приносят требования в следующем виде:

Я хочу, чтобы вы сделали кнопку.
Я хочу, чтобы вы сделали вот этот модуль.

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

На самом деле — нет. Как говорил Генри Форд «Если бы я спросил пользователей напрямую, что им нужно, они бы ответили — более быстрая лошадь». Так и в жизни — пользователи и заказчики часто формулируют требования в контексте решений и ошибка команды — слепо их принимать. Но заказчик чаще всего вообще не специалист в разработке продуктов, которые вы делаете. Он хочет решить свою проблему. А ваша задача — узнать, а какую проблему он хочет решить.

Какие вопросы стоит задавать заказчику, чтобы понять его истинные потребности?

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

Какие вопросы бы вы ему задали?

Можно начать задавать ему сразу вопросы про критерии, размеры, прочность коробки, цвета и прочие фичи и плюшки. И побежать ее скорее делать, взяв предоплату с вашего заказчика. Что получиться в итоге? Скорее всего, разочарованный заказчик и потраченные деньги. Коробка, может, и классной получится, но решит ли она его проблему?)

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

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

Главный вопрос, который стоит задать вашему заказчику: «Зачем тебе нужна эта коробка?»

Ведь в ответе кроется суть: коробка может быть для разных целей:

  • Для того, чтобы убирать вещи в не сезон, например, летом убираются в коробку зимние вещи;

  • Для удобства сортировки вещей в шкафу;

  • Для того, чтобы перевезти вещи в новую квартиру.

и еще 100500 вариантов.

От этого зависит, какое решение вы будете создавать.

Например, вашему заказчику нужно убирать зимние вещи летом, чтобы освобождать место в шкафу, так как места у него не так много. Таким образом, вы знаете, какая у него задача и проблема: Задача — Иметь место для актуальных вещей в шкафу, проблема — мало места в шкафу, вещи мнутся.

Выявляйте пользовательские потребности и формулируйте Пользовательские истории

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

Например, это может быть: «Я, как холостой мужчина 40 лет, хочу убирать зимние вещи из шкафа, и тогда у меня будет место, чтобы повесить летние вещи».

И на этом этапе, когда вы узнали потребность вашего пользователя, вы можете задать ему вопросы:

  • А какие это вещи?

  • Насколько их много?

и так далее.

Далее несете это требование команде и вместе придумываете решение, которое наиболее полно решит проблему заказчика, будет дешевле для заказчика и проще для вас в реализации. И это может быть вовсе не коробка ;)

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

Спрашивайте больше «зачем», разбирайтесь в проблеме заказчика, и только потом предлагайте более простое и наилучшее решение

Вторая ошибка — писать требования в письменном виде и молча передавать в разработку, ставя задачи

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

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

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

Третья ошибка — описывать большой объем требований наперед

В Agile процесс разработки требования идет итеративно, в зависимости от фокуса команды в данный момент итерации. Не стоит писать детальные требования дальше чем на 1-2 итерации, так как все, скорее всего, поменяется. Не тратьте на это время. Формулируйте требования в пользовательских историях в легком формате и храните их в беклоге. А при решении о скором создании — собирайтесь и обсуждайте детали с командой, фиксируя критерии приемки.

Что такое критерии приемки?

Это детали, которые вы выясняете в процессе проработки пользовательской истории. И также это список, по которому вы будете проверять — выполнена ли пользовательская история или нет.

Например: «Я, как холостой мужчина 40 лет, хочу убирать зимние вещи из шкафа, и тогда у меня будет место, чтобы повесить летние вещи».

Критерии приемки:

  • Вещи сложены в специальный отсек и не мнутся

  • Объем вещей — 100 литров

  • Отсек должен быть в высоту не более 55 см

  • В отсеке должно быть разделение для верхней одежды

Если резюмировать, рецепт Agile-требований такой:

  • Не тратьте месяцы на то, чтобы описать досконально все в начале проекта, идите последовательно, формируйте более детальные требования на 1-2 итерации вперед и описывайте их в легковесном формате в виде критериев приемки.

  • Вместо фокуса на решении, сформулируйте основные пользовательские истории и далее в ходе разработке уточняйте их. Задавайте вопросы «Зачем», когда вам приносят готовое решение на вход, чтобы разобраться в проблеме пользователя и заказчика.

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

А если вам понравилась статья, жду в своем телеграмм-канале и на сайте.

Приглашаем всех желающих на открытое занятие «Бизнес для ИТ или ИТ для бизнеса?», на котором обсудим:

— Зачем компании нужен БА?
— Как БА взаимодействует с другими участниками процесса?
— Почему БА важен для успешной трансформации компании?

Регистрация доступна по ссылке.

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

Ошибка №1: упущение стейкхолдеров

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

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

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

Код курса
BAPM

Ближайшая дата курса

по запросу

Длительность обучения
ак.часов

Стоимость обучения
0 руб.

Ошибка №2: формулировки на языке интерфейсов

При том, что люди лучше воспринимают наглядные картинки, чем текст, представлять требования в виде макетов графических форм UI и диаграмм бизнес-процессов – это грубая ошибка. Сюда же относится включение элементов пользовательского интерфейса в формулировку требований. Например, «Система отправляет введенные данные после нажатия пользователем кнопки ОТПРАВИТЬ». Кнопки, чек-боксы, радио-кнопки, выпадающие списки, всплывающие окна, цвета и размеры, а также прочие элементы UI/UX – это область ответственности дизайнера/проектировщика интерфейса. При этом аналитик определяет требования к интерфейсам пользователя UX, а также нефункциональные требования, которые относятся к взаимодействию с пользователем, например, удобство практического использования, включая простоту ежедневной работы и обучения.

В частности, требование к удобству пользовательского интерфейса может быть сформулировано как необходимость соответствия предписаниям ГОСТ Р 52872-2019 или возможность добраться до любого конверсионного элемента UI не более чем за 3 клика. Правда, в этом случае, необходимо четко обозначить, что именно понимается под конверсионным элементом и какую конверсию как отношение чего-то к чему-то это позволяет рассчитать.

При этом BABOK®Guide включает прототипирование в список наиболее полезных для бизнес-аналитика техник как метод раннего проектирования продукта для выявления и подтверждения потребностей стейкхолдеров через итеративной процесс создания модели или дизайна требований. Но, в отличие от дизайнов, требования носят универсальный характер, не зависят от особенностей реализации и интерфейсов. Бумажные или цифровые прототипы пригодятся для улучшения впечатления пользователей, оценки вариантов дизайна и как основа конечного решения. Однако, созданные аналитиком прототипы не могут рассматриваться как требования к реализации. В ТЗ или SRS такие макеты UI-форм могут включаться как иллюстративные дополнения (приложения), а не входные данные для команды разработки. Подробнее про технику прототипирования читайте в новой статье.

Основы бизнес-анализа: вход в профессию для начинающих

Код курса
INTRO

Ближайшая дата курса

27 марта, 2023

Длительность обучения
24 ак.часов

Стоимость обучения
50 000 руб.

Ошибка №3: недостаточная детализация требований в ТЗ

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

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

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

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

  • для Заказчика нужно, чтобы продукт решал его бизнес-проблемы с пользой, измеримой в деньгах или других точных показателях (время, количество клиентов);
  • сможет ли Разработчик/ИТ-Архитектор на основании вашего ТЗ разработать схему базы данных и выбрать наиболее эффективные технологии для реализации требований к надежности, отказоустойчивости, доступности, расширяемости, переносимости и безопасности?
  • помогут ли Тестировщику ваши сценарии в виде use case составить тест-кейс для верификации поведения продукта?
  • наконец, поймет ли Менеджер проекта объем работы исходя из определенных требований?

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

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса
TTIS

Ближайшая дата курса

8 февраля, 2023

Длительность обучения
12 ак.часов

Стоимость обучения
20 000 руб.

А практически усвоить приемы разработки требований и их спецификации в виде ТЗ вы сможете на курсе «Разработка ТЗ на информационную систему» в нашей Школе прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве.

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

20 ВИДОВ ПРОГРАММНЫХ ДЕФЕКТОВ, КОТОРЫЕ ДОЛЖЕН ЗНАТЬ КАЖДЫЙ ТЕСТЕР

В этой статье мы обсудим самые распространенные типы ПО дефекты и способы их выявления.

Что такое дефект?

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

Обязательно прочтите: Разница между дефектом, ошибкой, ошибкой и сбоем

Типы программных ошибок при тестировании программного обеспечения

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

Ошибки программного обеспечения подразделяются на три типа:

  1. Дефекты программного обеспечения по своей природе
  2. Дефекты программного обеспечения по их приоритету
  3. Дефекты программного обеспечения по их серьезности

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

#1. Дефекты программного обеспечения по своей природе

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

#1. Функциональные ошибки

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

Функциональные ошибки можно исправить, выполнив функциональное тестирование.

#2. Ошибки на уровне модуля

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

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

#3. Ошибки уровня интеграции

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

Ошибки интеграции можно исправить, выполнив интеграционное тестирование.

#4. Дефекты юзабилити

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

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

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

#5. Дефекты производительности

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

Ошибки юзабилити можно исправить, выполнив тестирование производительности.

#6. Дефекты безопасности

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

Ошибки безопасности можно исправить, выполнив тестирование безопасности.

#7. Дефекты совместимости

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

Ошибки совместимости можно исправить, выполнение тестирования совместимости.

#8. Синтаксические ошибки

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

#9. Логические ошибки

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

Общие симптомы логических ошибок включают:

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

Чтобы найти и исправить логические ошибки, тестировщикам необходимо иметь четкое представление о коде программы и о том, как она должна работать. Часто лучший способ найти такие ошибки — использовать инструменты отладки или пошаговое выполнение, чтобы отслеживать выполнение программы и видеть, где что-то идет не так.

#2. Дефекты программного обеспечения по степени серьезности

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

#1. Критические дефекты

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

#2. Серьезные дефекты

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

#3. Незначительные дефекты

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

#4. Тривиальные дефекты

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

#3. Дефекты программного обеспечения по приоритету

#1. Дефекты с низким приоритетом

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

#2. Дефекты со средним приоритетом

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

#3. Дефекты с высоким приоритетом

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

Некоторые распространенные примеры дефектов с высоким приоритетом включают:

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

#4. Срочные дефекты

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

#4. Дополнительные дефекты

#1. Отсутствующие дефекты

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

#2. Неправильные дефекты

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

#3. Дефекты регрессии

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

Часто задаваемые вопросы — Типы программных ошибок< /h2>

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

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

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

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

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

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

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

Как найти лежащие в основе ошибки программного обеспечения?

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

1) Репликация. Первым этапом является воспроизведение ошибки. Это включает в себя попытку воспроизвести тот же набор шагов, в котором возникла ошибка. Это поможет проверить, является ли ошибка реальной или нет.
2) Изоляция. После того, как ошибка воспроизведена, следующим шагом будет попытка ее изоляции. Это включает в себя выяснение того, что именно вызывает ошибку. Для этого тестировщики должны задать себе несколько вопросов, например:
– Какие входные данные вызывают ошибку?
– При каких различных условиях возникает ошибка?
– Каковы различные способы проявления ошибки?
3) Анализ: после Изолируя ошибку, следующим шагом будет ее анализ. Это включает в себя понимание того, почему возникает ошибка. Тестировщики должны задать себе несколько вопросов, таких как:
– Какова основная причина ошибки?
– Какими способами можно исправить ошибку?
– Какое исправление было бы наиболее эффективным? эффективно?
4) Отчет. После анализа ошибки следующим шагом является сообщение о ней. Это включает в себя создание отчета об ошибке, который включает всю соответствующую информацию об ошибке. Отчет должен быть четким и кратким, чтобы разработчики могли его легко понять.
5) Проверка. После сообщения об ошибке следующим шагом является проверка того, была ли она исправлена. Это включает в себя повторное тестирование программного обеспечения, чтобы убедиться, что ошибка все еще существует. Если ошибка исправлена, то тестер может подтвердить это и закрыть отчет об ошибке. Если ошибка все еще существует, тестировщик может повторно открыть отчет об ошибке.

Заключение

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

Задавая правильные вопросы и применяя правильные методы, тестировщики могут помочь обеспечить чтобы дефекты обнаруживались и исправлялись как можно раньше в процессе разработки.
TAG: qa

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

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

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

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

  • методология,
    технология и уровень автоматизации
    системного и структурного
    проектирования ПС, а также непосредственного
    программирования
    компонентов;

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

  • класс
    ПС, масштаб (размер) и типы компонентов,
    в которых обнаруживаются
    ошибки;

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

  • виды
    и достоверность эталонов-тестов, которые
    используются для обнаружения
    ошибок.

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

  • ошибки,
    обусловленные сложностью компонентов
    и ПС в целом и наиболее
    сильно влияющие на размеры модификаций;

  • ошибки
    вследствие большого масштаба — размера
    комплекса программ,
    а также высоких требований к его
    качеству;

  • ошибки
    планирования и корректности требований
    модификаций часто
    могут быть наиболее критичным для
    общего успеха ЖЦ ПС и системы;

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

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

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

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

  • программные
    ошибки, вследствие неправильной записи
    текстов программ
    на языке программирования и ошибок
    трансляции текстов изменений
    программ в объектный код;

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

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

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

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

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

К
группе факторов, влияющих на сложность
ошибок комплексов
программ, относятся:

  • величина
    — размер модифицируемой программы,
    выраженная числом
    строк текста, функциональных точек или
    количеством программных модулей в
    комплексе;

  • количество
    обрабатываемых переменных или размер
    и структура памяти, используемой для
    размещения базы данных корректировок;

  • трудоемкость
    разработки изменений комплекса программ;

  • длительность
    разработки и реализации корректировок;

  • число
    специалистов, участвующих в ЖЦ комплекса
    программ.

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

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

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

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

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

Масштаб
—размер
комплексов программ и их изменяемой
части наиболее
сильно влияет на количество ошибок, а
также на требования к качеству
ПС
(см. лекцию 5). Качество откорректированного
ПС характеризуется
многими показателями, состав которых
зависит от класса и конкретного
назначения комплекса программ. Ниже
предполагается, что всегда модификации
ПС соответствуют заданному функциональному
назначению и основным требованиям
заказчика к их качеству. По мере увеличения
размера и повышения требований к качеству
ПС и его корректировкам
затраты на обнаружение и устранение
ошибок ПС увеличиваются
все более высокими темпами. Одновременно
расширяется диапазон неопределенности
достигаемого качества. В зоне высокого
качества программ возрастают трудности
измерения этих характеристик, что может
приводить
к необходимости изменения затрат в
несколько раз в зависимости
от применяемых методов и результатов
оценки качества ПС. Вследствие этого в
ЖЦ сложных и сверхсложных ПС всегда
велики проявления неустраненных ошибок
и недостаточна достоверность оценок
достигнутого
качества.

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

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

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

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

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

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

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

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

При
автономной и в начале комплексной
отладки версий ПС относительная доля
системных ошибок может быть невелика
(около 10%), но она существенно
возрастает (до 35—40%) на завершающих
этапах комплексной отладки новых базовых
версий ПС. В процессе сопровождения
системные ошибки являются преобладающими
(около 60—80% от всех оши-

бок).
Следует также отметить большое количество
команд, корректируемых при исправлении
каждой такой ошибки (около 20—50 команд
на одну ошибку).

Алгоритмические
ошибки программ
трудно поддаются обнаружению
методами статического автоматического
контроля. Трудность их обнаружения
и локализация определяется, прежде
всего, отсутствием для многих логических
программ строго формализованной
постановки задачи,
полной и точной спецификации, которую
можно использовать в качестве
эталона для сравнения результатов
функционирования программ. К алгоритмическим
ошибкам следует отнести, прежде всего,
ошибки, обусловленные
некорректной постановкой требований
к функциональным задачам,
когда в спецификациях не полностью
оговорены все условия, необходимые
для получения правильного результата.
Эти условия формируются и уточняются
в значительной части в процессе
тестирования и выявления ошибок в
результатах функционирования программ.
Ошибки, обусловленные
неполным учетом всех условий решения
задач, являются наиболее
частыми в этой группе и составляют до
50—70% всех алгоритмических ошибок.

К
алгоритмическим ошибкам следует отнести
также ошибки интерфейса
модулей и функциональных групп программ,
когда информация, необходимая
для функционирования некоторой части
программы, оказывается не полностью
подготовленной программами, предшествующими
по
времени включения, или неправильно
передаются информация и управление
между взаимодействующими модулями.
Этот вид ошибок составляет около 10% от
общего количества, и их можно квалифицировать
как ошибки некорректной постановки
задач. Алгоритмические ошибки проявляются
в неполном учете диапазонов изменения
переменных, в неправильной оценке
точности используемых и получаемых
величин, в неправильном
учете корреляции между различными
переменными, в неадекватном
представлении формализованных условий
решения задачи в виде частных спецификаций
или блок-схем, подлежащих программированию.
Эти
обстоятельства являются причиной того,
что для исправления каждой алгоритмической
ошибки приходится изменять в среднем
около 20 команд (строк
текста), т.е. существенно больше, чем при
программных ошибках.

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

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

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

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

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

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

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

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

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

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

Технологические
ошибки документации
и фиксирования программ в памяти ЭВМ
составляют иногда до 10% от общего числа
ошибок, обнаруживаемых
при тестировании. Большинство
технологических ошибок выявляется
автоматически статическими методами.
При ручной подготовке текстов машинных
носителей при однократном фиксировании
исходные данные
имеют вероятность искажения около 10
«3—
10~4
на символ. Дублированной
подготовкой и логическим контролем
вероятность технологической
ошибки может быть снижена до уровня 10
5
—
10′7
на символ. Непосредственное
участие человека в подготовке данных
для ввода в ЭВМ и
при анализе результатов функционирования
программ по данным на дисплеях определяет
в значительной степени их уровень
достоверности и не позволяет полностью
пренебрегать этим типом ошибок в
программах.

В
примере
анализа ошибок конкретного крупного
проекта было
принято, что завершилась инспекция
начального запрограммированного кода
крупного ПС на предмет его соответствия
рабочей проектной спецификации,
в ходе которой было обнаружено 3,48 ошибки
на тысячу строк кода. Наибольшее
совпадение аппроксимации рэлеевской
кривой распределения
ошибок с фактическими данными установлено
для момента получения этих данных, ему
соответствует значение, равное также
3,48. Значения
числа ошибок на тысячу строк получены
при пересчетах на более ранние
этапы соответственно эскизного — (3,3)
и рабочего — (7,8) проектирования
программ. При прогнозировании в
соответствии с рэлеевской кривой
распределения вероятности проявления
дефектов программ на следующем
этапе квалификационного тестирования
компонентов следовало ожидать
обнаружения около 2,12 ошибки на тысячу
строк исходного кода.

В
случае сохранения той же закономерности
в момент поставки клиенту на
испытания программный продукт мог
содержать менее 0,07 ошибки на тысячу
строк кода. Отмечается также, что частость
проявления 0,1—0,05 ошибки
на тысячу строк кода можно считать
допустимой для ответственных
систем реального времени.

В
исследованиях 20 крупных поставляемых
программных продуктов, созданных в 13
различных организациях, коллективы
специалистов добились среднего уровня
0,06 дефекта на тысячу строк нового и
измененного программного
кода. При использовании структурного
метода в пяти проектах достигнуто
0,04—0,075 ошибки на тысячу строк. Таким
образом, уровень
ошибок около 0,05 на тысячу строк кода в
разных публикациях считается близким
к предельному для высококачественных
программных продуктов.

Другим
примером оценок уровня ошибок критического
ПС особенно высокого
качества может служить программный
продукт бортовых систем «Шаттла»,
созданный NASA.
По оценке авторов, в нем содержится
менее
одной ошибки на 10 000 строк кода. Однако
стоимость программного
продукта достигает 1000 $ за строку кода,
что в среднем в сто раз больше,
чем для административных систем, и в
десять раз больше, чем для ряда
ординарных критических управляющих
систем реального времени.

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

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

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

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

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

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

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

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

  • для
    управления рисками и их сокращения в
    рассматриваемых проектах
    сложных комплексов программ рекомендуется
    выделять три класса

276

рисков:
функциональной пригодности ПС,
конструктивных характеристик качества
и нарушения ограничений ресурсов при
реализации процессов ЖЦ ПС;

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #

  1. Главная

  2. Туториалы

  3. Программирование

  4. Процесс разработки программного обеспечения

Стив Макконнелл, в его книге «Быстрая разработка», подробно описывает как пользователи могут препятствовать сбору требований:

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

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

Проблемы инженеров / разработчиков

Возможные проблемы, вызванные инженерами и разработчиками во время анализа требований:

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

Решения проблем

Одно из решений проблемы общения состояло в том, чтобы нанять специалистов в деловом или системном анализе.

Методики, введённые в 1990-х — прототипирование, унифицированный язык моделирования (UML), сценарии использования и гибкая методология разработки, — также предназначены для решения описанных выше проблем.

Источник

7.2.3. Функциональное тестирование

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

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

В задачи функционального тестирования входят:

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

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

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

Предпосылки функционального тестирования:

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

7.3. Инфраструктура процесса тестирования ПС

Под инфраструктурой процесса тестирования понимается:

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

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

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

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

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

7.3.1. Методы поиска ошибок в программах

Международный стандарт ANSI/IEEE-729-83 разделяет все ошибки в разработке программ на следующие типы.

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

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

Отказ (failure) — это отклонение программы от функционирования или невозможность программы выполнять функции, определенные требованиями и ограничениями, что рассматривается как событие, способствующее переходу программы в неработоспособное состояние из-за ошибок, скрытых в ней дефектов или сбоев в среде функционирования [7.6, 7.11]. Отказ может быть результатом следующих причин:

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

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

Ошибки на этапах процесса тестирования.Приведенные типы ошибок распределяются по этапам ЖЦ и им соответствуют такие источники их возникновения [7.12]:

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

Рассмотрим процесс тестирования, исходя из рекомендаций стандарта ISO/IEC 12207, и приведем типы ошибок, которые обнаруживаются на каждом процессе ЖЦ.

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

Характерными ошибками этого процесса являются:

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

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

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

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

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

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

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

Все ошибки, которые возникают в программах, принято подразделять на следующие классы [7.12]:

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

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

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

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

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

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

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

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

На современном этапе развития средств поддержки разработки ПО (CASE-технологии, объектно-ориентированные методы и средства проектирования моделей и программ) проводится такое проектирование, при котором ПО защищается от наиболее типичных ошибок и тем самым предотвращается появление программных дефектов.

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

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

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

Приведем следующую классификацию типов отказов:

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

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

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

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

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

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

Источник

Время на прочтение
12 мин

Количество просмотров 14K

Небрежное отношение к разработке и управлению требованиями часто приводит к тому, что проекты по разработке программного обеспечения оказываются сложными или проваливаются. Вот десять распространенных ловушек, с которыми можно столкнуться, если не принимать требования всерьез. Я описываю симптомы, которые могут указывать на то, что вы стали жертвой одной из ловушек, а также некоторые возможные решения. Более подробную информацию обо всех этих ловушках можно найти в книге «Требования к программному обеспечению«, 3-е издание, авторы Karl Wiegers и Joy Beatty.

Первая ловушка: Непонимание того, что такое требования

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

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

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

Рисунок 1: Три уровня требований к программному обеспечению

Рисунок 1: Три уровня требований к программному обеспечению

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

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

Вторая ловушка: Недостаточное вовлечение клиентов

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

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

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

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

Третья ловушка: Нечеткие, двусмысленные и неполные требования

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

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

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

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

  • BA, который написал требования, и, возможно, другой опытный BA

  • Клиент или представитель отдела маркетинга, который их предоставил

  • Разработчик, который должен их реализовать

  • Тестировщик, который должен проверить их в продукте

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

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

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

4 ловушка: Неприоритетные требования

Симптомы: «Нам не нужно расставлять приоритеты в требованиях», — сказал представитель пользователя. «Они все важны, иначе я бы их вам не предоставил». Признание всех требований одинаково важными не помогает менеджеру проекта реагировать на новые требования или на изменения в реальности проекта (персонал, график, цели по качеству). Если неясно, какие функции можно отложить во время слишком распространенной «фазы быстрого анализа» в конце проекта, вы рискуете получить неприоритетные требования.

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

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

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

  • Высокий: должно быть включено в следующий релиз или итерацию

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

  • Низкий: мы можем прожить без этого, если это необходимо

Пятая ловушка: Создание функциональности, которую никто не использует

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

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

Определите класс пользователей, которым нужна каждая функция или сценарий использования. Написание пользовательских историй в форме «Как <type of user>(<тип пользователя>), я хочу <some goal>(<такую-то цель>), чтобы <some reason> (<такая-то причина>)» позволяет четко определить, какой класс пользователей получит выгоду.

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

Ловушка 6: Аналитический паралич

Симптомы: Если кажется, что разработка требований длится вечно, возможно, вы стали жертвой аналитического паралича. Новые версии SRS могут появляться так часто, что номера версий напоминают IP-адреса. Чрезмерно усердный BA может попытаться смоделировать все требования или создать прототип всей системы, прежде чем объявить требования готовыми к реализации. Возможно, лица, принимающие решения, так и не пришли к согласию относительно базовой линии требований. Аналитический паралич — это большой риск чисто водопадного подхода к разработке программного обеспечения.

Решения: Ваша реалистичная цель — это не идеальный SRS, а набор четко сформулированных требований, чтобы часть разработки могла продолжаться с приемлемым риском. Выберите такой жизненный цикл разработки, который позволит вам реализовывать части требований по мере их понимания. Инкрементные подходы к разработке, такие как agile, частично развились для того, чтобы избежать аналитического паралича. Обозначьте пробелы в ваших требованиях символом TBD (будет определено позднее) для обозначения дальнейших действий. Моделируйте и создавайте прототипы только сложных, новых или малопонятных частей системы, чтобы уточнить требования.

Седьмая ловушка: Расползание рамок

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

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

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

Расползание рамок часто указывает на то, что требования изначально были не учтены, поэтому эффективные методы получения требований очень важны. Установите значимый процесс для определения базового набора требований для следующего релиза или нового этапа разработки. Дополнительные идеи о том, как справиться с этой ловушкой, см. в моей статье «Managing Scope Creep: Why, When, and How».

8 ловушка: Несовершенный процесс внесения изменений

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

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

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

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

Девятая ловушка: Неэффективный анализ воздействия изменений

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

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

Десятая ловушка: Решения, представленные в виде требований

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

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

BA должен прислушиваться к сигналам, указывающим на то, что пользователи представляют решения, а не истинные требования. Когда вы слышите идею решения, задавайте вопросы, чтобы понять, какая реальная потребность стоит за каждым предлагаемым решением. Является ли эта идея решения истинным ограничением, которое должны соблюдать разработчики? Или это просто одно из представлений говорящего о том, как может быть реализована та или иная возможность?

Основные составляющие отличных требований

Эти десять ловушек — не единственные, скрывающиеся на минном поле требований, но они одни из самых распространенных и самых серьезных. Чтобы справиться с ними, попробуйте использовать следующие подходы.

  • Обучайте разработчиков, менеджеров и заказчиков как практическим требованиям, так и области применения.

  • Установите партнерские отношения между заказчиком и разработчиком.

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

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

  • Проводите как неформальные, так и формальные обзоры требований.

  • Заранее составляйте тесты на соответствие требованиям.

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

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

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

——————————————————————————————————————

Если вы интересуетесь требованиями к программному обеспечению, бизнес-анализом, управлением проектами, качеством программного обеспечения или консалтингом, Process Impact предлагает множество полезных публикаций, загрузок и других ресурсов. Последняя книга Карла — «The Thoughtless Design of Everyday Things».

Источник

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

Ошибка №1: упущение стейкхолдеров

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

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

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

Код курса
BAPM
Ближайшая дата курса

по запросу

Длительность обучения
ак.часов
Стоимость обучения
0 руб.

Ошибка №2: формулировки на языке интерфейсов

При том, что люди лучше воспринимают наглядные картинки, чем текст, представлять требования в виде макетов графических форм UI и диаграмм бизнес-процессов – это грубая ошибка. Сюда же относится включение элементов пользовательского интерфейса в формулировку требований. Например, «Система отправляет введенные данные после нажатия пользователем кнопки ОТПРАВИТЬ». Кнопки, чек-боксы, радио-кнопки, выпадающие списки, всплывающие окна, цвета и размеры, а также прочие элементы UI/UX – это область ответственности дизайнера/проектировщика интерфейса. При этом аналитик определяет требования к интерфейсам пользователя UX, а также нефункциональные требования, которые относятся к взаимодействию с пользователем, например, удобство практического использования, включая простоту ежедневной работы и обучения.

В частности, требование к удобству пользовательского интерфейса может быть сформулировано как необходимость соответствия предписаниям ГОСТ Р 52872-2019 или возможность добраться до любого конверсионного элемента UI не более чем за 3 клика. Правда, в этом случае, необходимо четко обозначить, что именно понимается под конверсионным элементом и какую конверсию как отношение чего-то к чему-то это позволяет рассчитать.

При этом BABOK®Guide включает прототипирование в список наиболее полезных для бизнес-аналитика техник как метод раннего проектирования продукта для выявления и подтверждения потребностей стейкхолдеров через итеративной процесс создания модели или дизайна требований. Но, в отличие от дизайнов, требования носят универсальный характер, не зависят от особенностей реализации и интерфейсов. Бумажные или цифровые прототипы пригодятся для улучшения впечатления пользователей, оценки вариантов дизайна и как основа конечного решения. Однако, созданные аналитиком прототипы не могут рассматриваться как требования к реализации. В ТЗ или SRS такие макеты UI-форм могут включаться как иллюстративные дополнения (приложения), а не входные данные для команды разработки. Подробнее про технику прототипирования читайте в новой статье.

Основы бизнес-анализа: вход в профессию для начинающих

Код курса
INTRO
Ближайшая дата курса

31 июля, 2023

Длительность обучения
24 ак.часов
Стоимость обучения
50 000 руб.

Ошибка №3: недостаточная детализация требований в ТЗ

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

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

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

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

  • для Заказчика нужно, чтобы продукт решал его бизнес-проблемы с пользой, измеримой в деньгах или других точных показателях (время, количество клиентов);
  • сможет ли Разработчик/ИТ-Архитектор на основании вашего ТЗ разработать схему базы данных и выбрать наиболее эффективные технологии для реализации требований к надежности, отказоустойчивости, доступности, расширяемости, переносимости и безопасности?
  • помогут ли Тестировщику ваши сценарии в виде use case составить тест-кейс для верификации поведения продукта?
  • наконец, поймет ли Менеджер проекта объем работы исходя из определенных требований?

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

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса
TTIS
Ближайшая дата курса

24 июля, 2023

Длительность обучения
12 ак.часов
Стоимость обучения
20 000 руб.

А практически усвоить приемы разработки требований и их спецификации в виде ТЗ вы сможете на курсе «Разработка ТЗ на информационную систему» в нашей Школе прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве.

Источник

Ограничения

К требованиям данного типа относятся
технические ограничения и бизнес-правила.
Технические ограничения (constraints) касаются
выбора возможности разработки внешнего
вида и структуры продукта, используемых
языков программирования, технологий и
платформ. Бизнес-правила (business rules)
включают корпоративные политики,
правительственные постановления,
промышленные стандарты и вычислительные
алгоритмы. Бизнес-правила не являются
требованиями к программному обеспечению,
потому что они находятся вне границ
любой системы. Однако они часто налагают
ограничения, определяя, кто может
выполнять конкретные требования, или
какими функциями должна обладать
система, подчиняющаяся соответствующим
правилам. Иногда бизнес-правила становятся
источником атрибутов качества, которые
реализуются в функциональности.
Следовательно, можно отследить
происхождение конкретных функциональных
требований вплоть до соответствующих
им бизнес-правил.

Иерархия требований

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

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

Рис 2. Иерархия требований

Стоимость ошибок в требованиях

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

Исследования Standish Group от 1994 года говорит
о следующем:

“В США ежегодно тратиться более 250
миллиардов долларов на разработку
приложений информационных технологий
в рамках примерно 175000 проектов. Средняя
стоимость проекта для крупных компаний
составляет 2,3 миллиона долларов, для
средних — 1,3 миллиона долларов, а для
небольших — 430 тысяч долларов”

Исследования Standish Group покали, что 31%
проектов будет прекращен до завершения.
Затраты на 52,7 % проектов составляют 189%
от первоначальной оценки.

Исходя из этого, исследователи Standish
Group показали, что американские компании
и правительственные учреждения потратят
81 миллиард долларов на программные
проекты, которые так и не будут завершены.
Эти же организации заплатят дополнительно
59 миллиардов долларов за программные
проекты, которые хотя и завершатся, но
значительно превысят первоначально
отведенное на них время.

К наиболее часто встречающимся факторам,
создающим «проблемы» в программных
проектах, относятся следующие:

  • Недостаток исходной информации от
    клиента: 13% проектов

  • Неполные требования и документы
    требований: 12% проектов

  • Изменение требований и документов
    требований: 12% проектов.

  • Несоответствия технологических навыков:
    7% проектов

  • Неправильный подбор персонала и
    выделение ресурсов: 6% проектов

  • Нереалистичное составление графиков
    и планирование времени: 4% проектов

  • Другое

Напротив, наиболее важными факторами
успеха проектов были выделены следующие:

  • Подключение к разработке пользователей:
    16% успешных проектов

  • Поддержка со стороны исполнительного
    руководства: 14 %

  • Ясная постановка требований: 12%

Европейская инициатива по обучению и
совершенствованию процесса программирования
(ESPITI) в 1995 году провела исследования и
подтвердила результаты StandishGroup. Выявленные
ESPITI проблемы в разработке программного
обеспечения представлены на рис. 3:

Рис 3. Проблемы разработки программного
обеспечения

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

В таблице 1 представлены результаты
исследования, проведенного в 1994 году
Каперсом Джонсом [1], и в ней приводятся
данные о вероятном количестве возможных
дефектов и средней эффективности их
устранения разработчиками, посредством
тестирования, контроля и других методов.

Таблица 1 — Характеристика дефектов

Источник дефектов

Вероятность
возникновения

Эффективность
устранения

Оставшиеся
дефекты

Требования

20%

77%

0,23

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

25%

85%

0,19

Кодирование

35%

95%

0,09

Документация

12%

80%

0,12

Неправильное
внедрение

8%

70%

0,12

В целом

100%

85%

0,75

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

Исследования последних лет показали,
что успешные компании тратят на разработку
требований 28% своих ресурсов и 38,5%
человеко-часов.

Европейское исследование показало, что
компании, которые тратят вдвое больше
усилий на разработку требований, чем
остальные (а среднее значение по индустрии
— 14%), разрабатывают продукт быстрее.

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

Рис 4. Стоимость устранения ошибок

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

Эксперты в области разработки программного
обеспечения утверждают, что переделывание
ошибок в требованиях может обойтись в
25-40% общего бюджета проекта и 70-85% бюджета
переделок. В таблице 2 приведен пример
переделывания программного проекта
[1], подтверждающий данные цифры.

«Представьте приложение, в котором
50000 строк кода. Оно разрабатывается
командой из шести программистов, одного
руководителя проекта, двух инженеров
по тестированию и одного аудитора
качества. Для определения сроков
разработки предположим, что написание
кода — это критический путь (и это верно
для большинства проектов). Исходя из
продуктивности 350 строк отлаженного
кода в месяц, расчетное время разработки
составит 24 месяца: т.е. 50000 строк, 350
строк/месяц, 6 человек. При затратах в
10000 долларов на каждого участника
разработки в месяц, общий бюджет проекта
составит порядка 2,4 миллиона долларов.
При такой стоимости, даже если в лучшем
случае 30% бюджета проекта будет потрачено
на переписывание кода, то цена переделывания
составит 720 тысяч долларов. Если 70% от
суммы тратиться на устранение ошибок,
возникших при составлении требований,
то их суммарная стоимость составит
больше 500 тысяч долларов».

Таблица 2 — Пример стоимости исправления
ошибок

Критерий

Значение

Количество строк
кода

50,000

Число разработчиков

6

Человеко-месяцы
написания кода

142.9

Время готовности
продукта

24 месяца

Затраты на работника
в месяц

$10,000

Общая стоимость
разработки

$2,400,000

Общая стоимость
переделывания (30%)

$720,000

Общая стоимость
устранения ошибок ТЗ (≈»70%)

$504,000

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

Таблица 3 — Коэффициенты возврата
инвестиций при снижении ошибок в
требованиях

Критерий

Вариант 1

Вариант 2

Вариант 3

Снижение кол-ва
ошибок в требованиях (%)

10%

20%

40%

Экономия средств в
типовом проекте

$50400

$100800

$201600

Сокращение сроков
готовности (месяцы)

1.0

1.7

2.5

Время возврата
инвестиций (месяцы)

9.5

4.7

2.4

Окупаемость инвестиций
в Первом проекте (%)

153%

407%

913%

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

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

Соседние файлы в папке 09.17.12

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
Источник

  • Ошибки процесса контроля последствия этих ошибок
  • Ошибки прошлых лет что это такое
  • Ошибки профессиональной деятельности медсестры
  • Ошибки прошлых лет счет 206
  • Ошибки протокола q 931