- •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. Роли участников команды бп.
20.Обсуждения: сквозной структурный контроль.
1) Концептуальное обсуждение. Обычно на начальной стадии, вместе с заказчиком и всей командой.
2) Административное обсуждение. Команда+Администрация. Что сделали вчера, что делаем сегодня.
3) Рабочее обсуждение – сквозной структурный контроль. Обсуждение проблем, обнаружение ошибок. Оценка работы по ошибкам после сессии. Можно проводить без руководства.
21.Принципы и виды отладки программ. Стратегии тестирования. Автономная и комплексная отладка.
Отладка программного средства (ПС) – деятельность, направленная на обнаружение и исправление ошибок в нем с использованием процесса выполнения его программ.
Тестирование ПС – процесс выполнения его программ на некотором наборе данных, для которого заранее известен результат применения или правила поведения программ.
Тест – набор данных, на котором производится тестирование.
Итак, отладка представляет собой итерационный процесс, состоящий из этапов тестирования, поиска ошибок и исправления программы:
тестирование, в результате которого может быть обнаружена ошибка;
поиск места ошибок в программе;
изменение программы для устранения ошибок.
При отладке отыскиваются и исправляются ошибки, которые обнаружены при тестировании. Тестирование не гарантирует правильность программного средства, а демонстрирует его ошибки. В процессе тестирования решаются две задачи:
подготовить наиболее полный набор тестов;
определить конец отладки (подготовлены тесты на все случаи и при последнем тестировании обнаружено мало ошибок).
Для подготовки набора тестов, который при заданном их количестве или при заданном времени обнаруживал бы наибольшее количество ошибок, необходимо выбрать рациональную стратегию тестирования. Эта стратегия лежит между двумя крайними подходами. Первый из них ориентирован на тестировании на основе спецификации, а второй – на основе текстов программ. Первый чаще применим на начальных стадиях разработки, второй – на завершающих. Оптимальная стратегия должна отвечать принципу, согласно которому для каждого программного документа, в том числе, и текста программ, должен проектироваться необходимый набор тестов.
Различают два вида отладки. Автономная определяет тестирование только части программы или группы программ, комплексная предполагает тестирование системы в целом, включая документацию.
На вход процесса тестирования поступают исходные данные и текст программы, если необходимо. Результат сравнивается с ожидаемым, если обнаружена ошибка – она исправляется, а интенсивность потока ошибок служит исходными данными для модели надежности, формирующей прогноз.
Принципы тестирования:
1) тестирование – ключевая задача, поручать ее нужно наиболее квалифицированным работникам; 2) тест хорош, если он с высокой вероятностью выявляет ошибки, а не демонстрирует правильность;
3) Тест готовится для правильных и неправильных данных;
4) Нужно избегать невоспроизводимых тестов;
5)Не следует упрощать программу для тестирования;
6)Если в программе были изменения, необходим прогон всех тестов.
22.Правила («Заповеди») тестирования.
Тестирование – ключевая задача, ее следует поручать наиболее квалифицированным специалистам. Полноценное тестирование своих программ лучше поручать другим.
Тест хорош, если он с высокой вероятностью выявляет ошибки, а не демонстрирует правильность.
Тесты должны готовиться как для правильных, так и для неправильных данных.
Необходимо избегать невоспроизводимых тестов, документировать их пропуск через компьютер; детально изучать результаты каждого теста.
Не следует упрощать программу для тестирования. Каждый модуль подключайте к программе только один раз; никогда не изменяйте программу, чтобы облегчить ее тестирование.
Если в программе были изменения, необходим прогон всех тестов.
