Характер используемой технологии проектирования

Выделяют методы, относящиеся к двум основным классам технологий:

• каноническая (твердо установленная) технология - ориентирована на использование главным образом каскадной модели жизненного цикла АС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.;

• индустриальная технология.

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

• автоматизированное (использование CASE-технологий);

• типовое (параметрическое - или модельно-ориентированное)проектирование.

9. Разработка детальных спецификаций функциональных требований

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

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

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

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

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

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

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

Отладка кода программного продукта.

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

· узнавать текущие значения переменных;

· выяснять, по какому пути выполнялась программа.

Существуют две взаимодополняющие технологии отладки.

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

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

Место отладки в цикле разработке программе

1. Программирование — внесение в программу новой функциональности, исправление ошибок в имеющейся.

2. Тестирование (ручное или автоматизированное; программистом, тестером или пользователем; «дымовое», в режиме чёрного ящика или модульное…) — обнаружение факта ошибки.

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

4. Отладка — обнаружение причины ошибки.

Инструменты

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

Инструменты отладки

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

Методологии и уровни тестирования.

Методологии тестирования

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

При тестировании методом белого ящика (white-box testing, также говорят — прозрачного ящика, оно же структурное тестирование), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого программного обеспечения.

Рисунок 3. Метод белого ящика

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

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

Рисунок 4. Метод черного ящика

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

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

Рисунок 5. Метод серого ящика

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

Уровни тестирования

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

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

· Системное тестирование — тестируется интегрированная система на её соответствие требованиям.

· Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться программа.

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

Не нашли, что искали? Воспользуйтесь поиском по сайту: