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

Основные задачи этапа:

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

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

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

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

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

Разработка моделей базы данных и приложений. Проектирование физической реализации системы.

28.Тестирование ис. Белый ящик. Покрытие операторов. Покрытие решений. Покрытий условий. Примеры.

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

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

3. Проверяются не только правильно рабочие моменты а так же места с ошибками.

4. Необходимо проверить не только то, что должна делать программа, но и не делает ли она то, что не должна делать.

5. Удачным считается тот тест, который обнаруживает ошибку.

6. Необходимо детально исследовать результаты работы каждого теста.

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

8. Никакое тестирование не может быть доказательством правильности программы.

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

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

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

2. Автономное тестирование внутренней структуры компонента программной системы методами белого ящика на соответствие проекту компонента. Исправление обнаруженных ошибок путем отладки.

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

4. Тестирование функционирования подсистемы методами черного ящика для выявления компонентов не работоспособных в составе системы. Ошибочные компоненты исправляются путем отладки и повторного автономного тестирования.

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

6. Завершенная программная система проходит приемо-сдаточные испытания – тестирование всей системы в присутствии заказчика или представителей будущих пользователей этой системы.