Принципиальные решения начальных этапов проектирования:

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

Последовательность разработки ТЗ.

Устанавливают:

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

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

• уточняют среду функционирования ПО (конкретную комплектацию и параметры АО, версию ОС и др ПО);

• действия программы в случае сбоев оборудования и энергоснабжения.

Принципиальные решения начальных этапов проектирования

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

выбор архитектуры ПО;

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

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

Различают четыре типа пользовательских интерфейсов:

• примитивные – реализуют единственный сценарий;

• меню – реализуют множество сценариев работы, операции которых организованы в иерархические структуры;

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

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

выбор подхода к разработке (структурного или объектного);

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

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

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

выбор языка и среды программирования.

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

Язык может быть определен:

•  организацией, ведущей разработку; например, если фирма владеет лицензионным вариантом C++ Builder, то она будет вести разработки преимущественно в данной среде;

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

•  устоявшимся мнением («все разработки подобного рода должны выполняться на C++ или на Java или на ...») и т.п.

Выбор среды программирования.

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

Наиболее часто используемыми являются визуальные среды Delphi, C++ Builder фирмы Borland (Inprise Corporation), Visual C++, Visual Basic фирмы Microsoft, Visual Ada фирмы IBM и др. В общем случае, если речь идет о выборе между этими средами, то он в значительной степени должен определяться характером проекта.

Выбор или формирование стандартов разработки.

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

• стандарт проектирования;

• стандарт оформления проектной документации;

стандарт интерфейса пользователя.

№58 Стандарт проектирования

должен определять:

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

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

•  требования к конфигурации рабочих мест разработчи-ков, включая настройки ОС и CASE-средств;

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

Стандарт оформления проектной документации должен регламентировать:

•  комплектность, состав и структуру документации на каждой стадии;

•  требования к ее содержанию и оформлению;

Стандарт интерфейса пользователя должен определять:

•  правила оформления экранов (шрифты и цветовую палитру), состав и расположение окон и элементов управления;

•  правила пользования клавиатурой и мышью;

•  правила оформления текстов помощи;

•  перечень стандартных сообщений;

• правила обработки реакции пользователя.

№59 ТЕСТИРОВАНИЕ И ОТЛАДКА ПО

Стадии тестирования. Принципы тестирования.

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

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

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

№60 Формирование тестовых наборов СТ иФН.

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

Существуют два подхода к формированию тестов: структурный и функциональный.

Структурный подход базируется на том, что известна структура и алгоритмы тестируемого ПО, («стеклянный ящик»). Тесты строят так, чтобы проверить правильность реализации заданной логики в коде программы.

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

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

№61 Ручной контроль ПО: инспекция исходного текста, сквозные просмотры, проверка за столом.

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

Основными методами ручного контроля являются:

•  инспекции исходного текста,

•  сквозные просмотры,

•  проверка за столом.

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

В эту группу входят: автор программы, проектировщик, специалист по тестированию и координатор — компетентный программист, но не автор программы.

Общая процедура инспекции предполагает следующие операции:

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

•  программист рассказывает о логике работы программы и отвечает на вопросы инспекторов;

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

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

•  участникам заранее выдают листинг программы;

•  предлагают несколько тестов;

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

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

№62 Структурное тестирование.

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

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

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

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

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

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

При функциональном тестировании различают следующие методы формирования тестовых наборов:

• эквивалентное разбиение;

• анализ граничных значений;

• предположение об ошибке.

Эквивалентное разбиение.

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

Анализ граничных значений. Граничные значения - это значения на границах классов эквивалентности входных значений или около них. Анализ показывает, что в этих местах резко увеличивается возможность обнаружения ошибок. Например, если в программе анализа вида треугольника было записано А + В ≥ С вместо А + В > С, то задание граничных значений приведет к ошибке: линия будет отнесена к одному из видов треугольника.

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

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

№64 Тестирования модулей и комплексное тестирование.

Как при проектировании и кодировании возможно применение как восходящего, так и нисходящего подходов.

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

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

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

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