- •1. Общая характеристика процесса проектирования ис. Структура ис.
- •2. Классификация рынка ис.
- •3. Жизненный цикл программного обеспечения ис
- •6.Документирование потока событий. Основной поток. Альтернативный поток. Исключения. Примеры.
- •7. Диаграммы взаимодействия. Диаграммы последовательности. Объекты. Сообщения. Время жизни объекта. Рефлексивная связь. Примеры.
- •8.Диаграммы взаимодействия. Диаграммы кооперации. Примеры.
- •9.Диаграммы деятельностей. Потоки. Синхронизация, распараллеливание процессов. Примеры.
- •11.Отношения между классами. Ассоциация. Виды ассоциаций. Агрегация. Композиция. Наследование. Зависимость. Генерация программного кода. Примеры. Отношения между классами
- •13.Диаграммы компонентов. Модули. Включение классов в модули. Связи между компонентами. Примеры.
- •Диаграммы компонентов
- •14.Диаграммы размещений. Процессоры. Устройства. Примеры.
- •15.Каноническое проектирование ис. Гост 34.602-89. Стадии и этапы создания ис. Обследование. Техническое задание.
- •16.Методология моделирования предметной области. Структурная модель. Функциональная модель. Объектно-ориентированная модель. Синтетическая методика.
- •17.Исходные данные для проектирования. Процессные потоковые модели. Классификация процессов. Референтная модель бизнес-процесса. Проведение предпроектного обследования предприятий.
- •Выделение и классификация процессов
- •Проведение предпроектного обследования предприятий
- •Кодирование технико-экономической информации
- •Информационная база и способы ее организации
- •Моделирование данных
- •20.Разработка пользовательских интерфейсов. Типы интерфейсов. Сравнение интерфейсов.
- •21.Структура программных модулей.
- •22.Анализ и оценка производительности ис. Методы контроля проекта. Трудоемкость разработки программных средств.
- •Методы контроля проекта.
- •Трудоемкость разработки программных средств
- •23.Управление проектом ис. Управление производством программных средств. Управление разработкой программных средств. Организация коллективной разработки. Методы бригадной разработки.
- •Организация коллективной разработки
- •Методы бригадной разработки
- •24.Инструментальные средства проектирования ис.
- •Vantage Team Builder (Westmount I-case)
- •25.Типовое проектирование ис. Классы типового проектирования: элементные, подсистемные, объектные. Достоинства и недостатки.
- •26.Графические средства представления проектных решений.
- •27.Этапы проектирования ис с применением uml. Разработка модели бизнес-прецедентов
- •Разработка модели бизнес-объектов
- •Разработка концептуальной модели данных
- •Разработка требований к системе
- •Анализ требований и предварительное проектирование системы.
- •28.Тестирование ис. Белый ящик. Покрытие операторов. Покрытие решений. Покрытий условий. Примеры.
- •Разработка тестов методами белого ящика.
- •29.Эксплуатация ис. Этапы эксплуатации информационной системы
- •5.1. Приобретение имеющейся информации
- •5.2. Первоначальный сбор собственной информации
- •5.3. Обновление информации, ее анализ и распространение
- •34 Программирование компоненты “Оперативный учет”. Регистры. Регистр накопления. Регистр остатков. Измерения. Движения регистров. Примеры.
Разработка тестов методами белого ящика.
Стратегия белого ящика предполагает, что известна внутренняя структура тестируемой программы в виде описания алгоритма или исходного текста программы. При этом тестированию подвергается внутренняя логика программы.
Для полного тестирования программы при этом подходе необходимо выполнить исчерпывающее тестирование всех возможных путей выполнения алгоритма.
Число не повторяющих друг друга путей в сложных алгоритмах достигает астрономической величины, поэтому абсолютно достоверно проверить логику достаточно сложной программы невозможно. Приходится ограничиваться частичной проверкой программы.
Технология тестирования программной системы
После полной компоновки программной системы, ее необходимо подвергнуть испытаниям на соответствие требования, предъявленным к системе в задании на ее разработку. Для этого необходимо рассмотреть всю систему как черный ящик, на входе которого исходные данные, на выходе – результаты, которые связаны с входными данными некоторыми функциями. На входные, исходные данные и функции наложены ограничения, перечисление которых составляет сущность требований к программной системе. Затем по стратегии черного ящика разрабатываются тесты, пытающиеся обнаружить ошибки в реализации требований и ограничений.
Полный объем требований, подлежащих тестированию, определяется заданием на разработку и является индивидуальным для каждой программной системы. На практике выработан список обязательных требований, подлежащих тестированию в любой программной системе. Рассмотрим основные из обязательных тестов программных систем.
1. Тестирование удобства использования. Проверяется удобство и комфорт интерфейса с пользователем, с учетом квалификации пользователя и особенностей предметной области.
2. Тестирование удобства эксплуатации. В отличии от предыдущего теста проверяется удобство и комфорт работы с системой для обслуживающего персонала (администратора системы, системного программиста, оператора ЭВМ и т.д.).
3. Тестирование производительности системы в нормальных условиях эксплуатации на соответствие техническому заданию.
4. Тестирование предельных объемов. Система загружается критически большим и длительным объемом работы, соответствующим предельным требованиям задания на разработку, а также превышающим их.
5. Тестирование предельных нагрузок. Система загружается на предельную мощность (количество работы в единицу времени). В отличии от предельных объемов, здесь тестируются кратковременные большие нагрузки системы.
6. Тестирование защиты данных от несанкционированного доступа, как случайного, так и умышленного.
7. Тестирование требований к вычислительным ресурсам (оперативная память, быстродействие и т.д.) и конфигурации оборудования.
8. Тестирование совместимости с другими программами, с которыми будет взаимодействовать данная система.
9. Тестирование надежности и восстановления после отказов, если такие требования к системе предъявлены.
10. Тестирование документации на предмет полноты и удобства использования. Объем документации оговаривается в техническом задании. Необходимо проверить, достаточно ли сведений, необходимых для обучения пользователей, для технической эксплуатации, для устранения ошибок и модификации системы.