- •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. Роли участников команды бп.
19.Потоки данных и процессы их обработки Диаграммы потоков данных в методологии Гейна-Сарсона.
Структурный анализ – это систематический пошаговый подход к анализу требований и проектированию спецификаций системы независимо от того, является ли она существующей или создается вновь. Методология Гейна-Сарсона, основанная на идее нисходящей иерархической организации, наиболее ярко демонстрируют этот подход. Целью рассматриваемой методологии является преобразование общих, неясных знаний о требованиях к системе в точные (насколько это возможно) определения. Методология фокусируют внимание на потоках данных, их главное назначение – создание базированных на графике документов по функциональным требованиям. Методология поддерживается традиционными нисходящими методами проектирования спецификаций и обеспечивает один из лучших способов связи между аналитиками, разработчиками и пользователями системы.
Диаграммы потоков данных – это графическая составляющая методологий структурного анализа. Используются различные нотации этих диаграмм, такие, как нотация Йодана/ДеМарко или Гейна-Сарсона. Эти нотации основаны на семантически близких компонентах, различие лишь в форме изображения. Система моделируется как иерархический набор диаграмм потоков данных, детализирующих функции системы. Диаграммы показывают потоки данных между процессами, данные, которые хранятся в системе, интерфейсы с внешними по отношению к системе сущностями. Текстовое описание функций и данных нижнего уровня завершает информацию.
Диаграммы потоков данных – это идеализированное представление системы. Предполагается, что процессы (функции) происходят мгновенно, входы и выходы всегда доступны. Диаграммы не показывают последовательность выполнения функций, в отличие от графов преобразований, относящихся к структурному анализу реального времени, которые представляют поведенческие аспекты.
При применении нотации Гейна-Сарсона или аналогичных структурных методологий моделируемая система изображается как иерархически упорядоченное множество диаграмм потоков данных. Иерархическое упорядочение соответствует детализации процессов в системе. На диаграммах показываются потоки данных между процессами, данные, хранящиеся в системе и интерфейсы с внешними для системы сущностями. Потоки данных и функции нижнего уровня описываются текстуально.
Предполагается, что процессы протекают мгновенно, входы всегда доступны и на выходы всегда поступают данные. На диаграммах не показывается последовательность выполнения процессов, в отличие от графов преобразований
В силу того, что последовательность выполнения процессов явно не задана, а процесс может выполняться, как только у него будет достаточно исходных данных, ДПД пригодны для описания асинхронных (параллельных) процессов. Их согласование, синхронизация по данным, становится возможным в силу наличия компонента «хранилище данных». Если процесс, воспринимающий результирующие данные текущего процесса как входные, не может быть запущен, он получает их из хранилища, куда их помещает текущий процесс. Такая модель асинхронной обработки очень похожа на механизм сетей Петри.
DFD описывает:
функции обработки информации (работы, activities);
документы (стрелки, arrows), объекты, сотрудников или отделы, которые участвуют в обработке информации;
внешние ссылки (external references), которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы;
таблицы для хранения документов (хранилище данных, data store).
Гейн и Сарсон предложили классическую схему DFD немного усложнить. Он предложил ввести дополнительный объект, с помощью которого показываются места бизнес-процесса, в которых хранится информация, либо материальные ресурсы. Данный объект получил название – хранилище данных.
