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

Тестирование, применяемое для локализации ошибок.

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

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

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

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

Критерии завершения тестирования и отладки.

3 группы:

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

2. Критерии, основанные на оценке возможного количества ошибок. Возможное количество ошибок оценивают экспертно или по специальным методам. Завершают тестирование при нахождении 90% ошибок.

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

Оценочное тестирование

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

• удобство применения;

• тестирование на предельных объемах;

• тестирование на предельных нагрузках;

• тестирование удобства эксплуатации;

• тестирование защиты (информации);

• тестирование производительности;

• тестирование требований к памяти;

• тестирование конфигурации оборудования;

• тестирование совместимости;

• тестирование удобства установки;

• тестирование надежности;

• тестирование восстановления;

• тестирование удобства обслуживания;

• тестирование документации и др.

Инструментарий, применяемый для тестирования и отладки.

1. Тестовые мониторы. Включают:

- ядро (программа тестирования и оформления результатов).

- тестовая база (исходный тест и результаты).

- тестовое пространство.

2. Средства отслеживания тестового покрытия. Для выявления тестового покрытия программы, в том числе участков кода, пропущенных при тестировании.

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

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

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

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

   1. основную информацию об ошибке (номер, краткое описание, ключевые слова, приоритеты, состояние);

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

   3. персоналии (кто может иметь отношение, ответственный менеджер, инженер и др.);

   4. анализ и исправление;

   5. влияние исправления.

Ввод программы в действие

Выделяют:

1. Индивидуальную доставку (для конкретного заказчика).

2. коробочная доставка (CD).

3. Доставка через Интернет

– работа с программой осуществляется через Интернет из среды веб браузера.

- скачивание и установка на своем компьютере (свободно распространяемые, коммерческие программы).

При передаче пользователю желательна подготовка инсталляционной версии. Инструментарий – системы инсталляции. Рекомендации:

1. Дополнительно сжимать файл в самораспаковывающийся архив (ZIP)$

2. Всегда включать в архив файл readme с информацией о программе.

3. Убедиться, что инсталлятор дает возможность автоматически удалять программу (наличие деинсталлятора).

Эксплуатация и сопровождение.

Сопровождение – действия по повышению надежности программного продукта.

Основные классы задач сопровождения:

1. адаптация (модификация функций).

2. усовершенствование (добавление новых функций).

3. коррекция или исправление ошибок.

4. предупреждение проблем.

Основные типы сопровождения:

1. незначительные (локальные) изменения.

2. реструктурирование кода.

3. реинженеринг (перестройка программного продукта).

4. программирование заново.

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

Методы для повышения качества сопровождения.

1. выделение области связности изменений.

2. самодокументируемость изменений.

3. пассивное и активное сопротивление изменений.

Инструментарий, используемый при сопровождении:

1. С технической стороны (транслятор, отладчики, системы управления версиями тестов и др.).

2. Связанный с анализом и пониманием кода (средства реинженеринга и обратной инженерии (от кода к спецификации)).

3. Связанный с организационной стороной сопровождения (ведение базы данных ошибок).

Завершение эксплуатации

Начинается с оповещения пользователей о прекращении сопровождения программного продукта. Инструментарий – деинсталлятор.

Осуществляется с оповещения пользователей (заранее, в соответствии с договором) о прекращении сопровождения программного продукта ,

Основной инструментарий: системы декомпиляции.

Вспомогательные процессы

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

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

Заинтересованные лица: администраторы, инженеры, пользователи.

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

Для обозначения определения и установления состояния программных объектов в системе;

управлением изменениями и выпуском продуктов;

описание и сообщение о состоянии объектов и заявок на внесение изменений в них;

обеспечение полноты, совместимости и правильности объектов;

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

-Процесс обеспечения качеством

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

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

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

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

-Процесс верификации

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

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

-Аттестация

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

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

-Процесс совместного анализа

Является процессом оценки состояния и результатов работ по проекту.

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

-Процесс аудита

Является процессом определения соотвествия требованиям, планам и условиям договора. Выполняется двумя сторонами (ревизирующей и ревизируемой), участвующими в договоре.

-Процесс решения проблем

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

Организационные процессы

-Процесс управления

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

Список работ процесса управления:

--подготовка и опедедение области управления

--планирование

--выполнение и контроль.

-Процесс создания инфраструктуры

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

-Процесс усовершенствования

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

-обучение

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

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

Список работ:

--подготовка

--разработка учебных материалов

--реализация плана обучения

Разработка интерфейсов

Типы интерфейсов.

1. Процедурно ориентированные (примитивные, меню, со свободной навигацией).

2. Объектно-ориентированные (интерфейс прямого манипулирования).

Интерфейсы

1. Примитивный. Взаимодействие в консольном режиме. Реализуется сценарий: ввод данных->решение задачи->вывод результата. Возможна организация циклов.

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

3. Интерфейсы со свободной навигацией. Графические, WYSIWYG (what you see is what you get – что видишь, то и получишь). Поддерживают концепцию интерактивного взаимодействия с ПО и возможность прямого манипулирования объектами и информацией на экране.

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

При проектировании интерфейса следует учитывать психофизические особенности человека:

- фокус (внимание может фиксироваться только в одной точке).

- процесс обработки информации требует некоторого времени.

- существует мотивация.

- процесс переработки поступившей информации сравнивается с предыдущими данными (A I3 C).

- емкость краткосрочной памяти – 7±2 объекта, время хранения – 30 секунд.

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

- цвет ассоциируется с эмоциональным фоном.

- звук несет информацию, но может утомлять (следует предусмотреть средства отключения звука).

- время восприятия субъективно.

Существуют 3 модели интерфейсов:

1. Модель программиста. Учитывает платформу, ОС, подход к разработке, методы разработки, среду и язык разработки и т. п.

2. Модель пользователя. Интуитивные модели, формальные модели, задачи, процессы, инструменты, результаты и др.

3. Программная модель. Должна учитывать модель 1 и 2, тип интерфейса и т. п.

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

Анализ риска.

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

Типы рисков:

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

2. Риски, которые избежать нельзя.

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

Управление риском включает действия:

1. Идентификация – заключается в фиксации всех факторов беспокойства, связанных с проектом и поиски дефектов в плане разработки. Скептик желателен.

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

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

2. Планирование устранения

Выполняется с целью предупреждения рисков (устранения или снижения вероятности)

Способы предупреждения риска:

-внесение изменений в требования проекта (избежание риска)

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

3. Выбор приоритетов.

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

Таблица!!!

4. Устранение ли ументшение. Составляется план устранения.

Классические технологические процессы.

Возникновение и исследование идеи.

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

Определение и анализ требований.

В составлении требований участвует две стороны: покупатель, пользователь – разработчик.

Разработка и определение требований:

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

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

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

С точки зрения надёжности ПС, предпочтительна контролируемая пользователем разработка.

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

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

Функциональные требования (что должна делать система), нефункциональные требования (скорость, пропускная способность, надёжность и доступность, интерфейс, инструменты и язык, стандарты, платформы). Обратные требования – показывает что не должна делать система.

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

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

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

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

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

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

Процесс разработки и анализа тербований к системе. Включает требований к системе.

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

53