- •1.Предметная область. Прикладные программные системы (пс). Условия создания прикладных программных систем.
- •2.Автоматизированные системы управления и современные прикладные программные системы. Классификация, особенности.
- •3.Информационные системы и системы реального времени.
- •4.Требования к прикладным системам. Характеристика требований.
- •5.Требования к пс: адекватность предметной области; дружественность; возможность модификации.
- •6.Требования к пс: живучесть; защищенность. Проблемы переносимости. Универсальность и специализация.
- •7.Тиражирование прикладных систем. Тиражируемые, индивидуальные, слабо тиражируемые пс.
- •8.Модели жизненного цикла. Их характеристики.
- •9.Модели проектирования – каскадная, поэтапная, спиральная. Их особенности и области применения.
- •10.Планирование работы. Сетевой график.
- •11.Организация коллективной работы. Типы коллективов программистов.
- •12.Условия работы коллектива программистов.
- •13.Роли участников проекта: заказчик, пользователь, разработчик, руководитель, администратор.
- •14.Руководитель проекта, его действия по созданию работоспособного коллектива.
- •15.Профессиональная зрелость коллектива программистов.
- •16.Начальный этап проектирования. Анализ требований. Извлечение информации о предметной области.
- •17.Структурный системный анализ. Методология структурного системного анализа sadt (стандарт idef0).
- •18.Этап проектирования. Проектирование данных, функций, интерфейса, событий, выходных документов.
- •19.Потоки данных и процессы их обработки Диаграммы потоков данных в методологии Гейна-Сарсона.
- •20.Обсуждения: сквозной структурный контроль.
- •21.Принципы и виды отладки программ. Стратегии тестирования. Автономная и комплексная отладка.
- •22.Правила («Заповеди») тестирования.
- •23. Автономная отладка. Восходящее и нисходящее тестирование. Шаги автономного тестирования.
- •24. Комплексная отладка. Тестирование архитектуры, внешних функций, качества, документации, требований.
- •25. Особенности структурного тестирования (белый ящик). Его достоинства и недостатки.
- •26. Функциональное тестирование (черный ящик). Категории выявляемых ошибок.
- •27. Документирование прикладных программных систем. Этапы создания документации для тиражируемых систем.
- •28. Сдача прикладных систем в эксплуатацию.
- •29. Смена систем. Особенности проектирования «второй системы». Тактические приемы смены систем.
- •30. Особенности разработки заказных программных систем.
- •31. Подходы к перепроектированию технологических процессов: реинжиниринг бизнес-процессов (рбп) и асу.
- •32. Перепроектирование технологических процессов: модель управления по функциям и модель горизонтального потока. Цель и средства рбп.
- •33. Перепроектирование технологических процессов: риски. Критика подхода.
- •34. Перепроектирование технологических процессов и информационные технологии.
- •35. Классические и легкие методологии проектирования. Области применения.
- •36. Особенности подхода в методологии экстремального программирования.
- •37. Участники команды разработчиков в экстремальном программировании.
- •38. Экстремальное программирование: ценности, базовые принципы, виды деятельности.
- •39.Двенадцать правил экстремального программирования.
- •40. Риски легких методологий (на примере экстремального программирования).
- •41. Определение безнадежного проекта (бп). Категории бп.
- •42. Причины, порождающие безнадежные проекты.
- •43. Участники безнадежного проекта.
- •44. Отношение руководителя проекта и разработчиков к бп различных типов.
- •45. Оценка сложности проекта. Переговоры. Допустимые компромиссы.
- •46. Стратегии проведения переговоров в бп.
- •47. Человеческий фактор в бп: формирование команды.
- •48. Человеческий фактор в бп: условия работы.
- •49. Человеческий фактор в бп: мотивация, вознаграждение.
- •50. Роли участников команды бп.
23. Автономная отладка. Восходящее и нисходящее тестирование. Шаги автономного тестирования.
При автономной отладке модуль (программа) тестируется в некотором программном окружении. Окружение состоит как из отлаженных программных единиц, так и из неотлаженных. Рассматривают два пути тестирования: восходящий и нисходящий. Они соответствуют, как правило, выбранной стратегии разработки (снизу вверх или сверху вниз соответственно).
При восходящем тестировании, в силу того, что обстановка, в которой должен функционировать модуль, еще отсутствует, она должна быть создана. Для этого разрабатываются отладочные модули, обеспечивающие доступ к отлаживаемым.
При нисходящем тестировании нет подчиненных модулей, которые снабжают данными отлаживаемый модуль, следовательно, возникает необходимость создания заглушек для получения подчиненных данных.
Достоинства восходящего тестирования: простота подготовки тестов; полная реализация плана тестирования.
Недостатки восходящего тестирования: тесты готовятся в специальной форме; много отладочного программирования; необходимость специального тестирования сопряженных модулей.
Достоинства нисходящего тестирования противоположны недостаткам восходящего.
Недостаток нисходящего – тестовое состояние информационной среды готовится косвенно заглушками (имитаторами). Следовательно, требуется высокая квалификация тестировщика. Кроме того, невозможно выполнить полный план тестирования.
Общий принцип: наибольшего технологического эффекта можно добиться, сочетая нисходящие и восходящие методы.
Важный момент – тестирование сопряженных модулей. Спецификация модуля используется дважды: при его написании и при описании обращения к нему из другого модуля. Ошибки могут быть как в теле модуля, так и в интерфейсе, причем, с двух сторон. При нисходящем тестировании сопряжения проверяются автоматически: интерфейс определяется в вызывающем модуле. Это безусловный плюс данного подхода. При восходящем тестировании обращение идет из имитатора, следовательно, при сборке с остальными модулями, когда имитатор будет заменен реальным модулем, может проявиться ошибка.
Шаги автономного тестирования:
На основе спецификации готовится тест для каждого случая, каждой границы исходных данных, каждой области, каждого недопустимого значения.
По тексту программы проверяется каждое ветвление, чтобы убедиться, что каждое направление любого разветвления будет пройдено хотя бы на одном тесте. Добавляются недостающие тесты.
По тексту программы проверяется каждый цикл, в том числе его однократное, 0-кратное, бесконечное исполнение. Добавляются недостающие тесты.
Проверяется чувствительность к отдельным особым значениям входных данных – все такие значения должны входить в тесты. Добавляются недостающие тесты.
24. Комплексная отладка. Тестирование архитектуры, внешних функций, качества, документации, требований.
Комплексная отладка применяется к ПС в целом, значит, тестирование должно охватывать классы данных, относящихся к различным его аспектам. Рассмотрим основные направления тестирования при комплексной отладке.
Тестирование архитектуры. Цель – выявление несоответствия архитектуры и совокупности программ ПС. К моменту тестирования должна быть закончена автономная отладка. Ошибки проявляются во взаимодействии подсистем.
Тестирование внешних функций. Цель – выявление расхождений между функциональной спецификацией и совокупностью программ. Проводится методами черного ящика.
Тестирование качества. Цель – выявление нарушения требований к качеству. Один из наиболее трудных видов тестов. Не все характеристики качества удается протестировать. Обычно тестированию поддается: точность, устойчивость, защищенность, расширяемость, эффективность по времени, по памяти, по устройствам. Гораздо сложнее получить оценку степени надежности. К данному направлению относится и тестирование легкости применения, которая оценивается при тестировании документации.
Тестирование документации по применению. Цель – поиск несогласованности документации и ПС, неудобства применения ПС.
Тестирование требований. Цель – определение меры несоответствия требованиям. Обычно проводится на контрольных задачах, предоставляемых заказчиком. Здесь же оценивается соотношение со старым ПС, если оно было. Проводится во время опытной эксплуатации.