- •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. Роли участников команды бп.
16.Начальный этап проектирования. Анализ требований. Извлечение информации о предметной области.
Структурный анализ – метод исследования системы, который начинается с ее общего обзора и путем детализации приобретает иерархическую структуру. Цель метода – преобразование неточных знаний о реальном мире в точно сформированную структуру.
Виды требований: условия эксплуатации, функции системы, ограничение на разработку.
На этапе анализа определяется архитектура системы и ее функции, интерфейс, требования к программным и компьютерным ресурсам. Этим занимается и разработчик, и заказчик.
В результате этого этапа получается документ, называемый ТЗ. Средства анализа: Структура – BPWin, объект – Rational Rose. Язык: графический, поколения 4GL.
Правила структурного анализа:
1) Абстрагирование;
2) формализация;
3) сокрытие – сложные действия прячутся в простые конструкции
4) концептуальная общность
5) полнота
6) непротиворечивость
7) логическая независимость
8)независимость данных
9) Структурирование данных: описание групп данных и связей между группами
10) определение доступа пользователя: класс, уровень и т.д.
Основные сложности:
1) Самый дорогой этап
2) Сложно получить информацию от заказчика
3) Заказчик не понимает разработчика из-за недостаточности знаний в области информатики
4) чрезмерная подробность (данных от заказчиков)
5) Объемное ТЗ непонятно заказчику
6) маленькая спецификация ТЗ непонятна разработчику.
Прототипирование (этапы):
1. Контекстная диаграмма, в которой расписано предприятие.
2. Отдельные блоки, не увеличивающие общее количество входов и выходов
На этом этапе продумывается все окружение предприятия.
2. Далее каждый из квадратов разбивается до тех пор, пока все не будет понятно. На первом листе располагается не более 10 квадратов, т.к. иначе количество стрелок сильно увеличится. Если что-то преобразуется в квадрате, то оно считается входом, иначе – управлением. Преобразованные документы – управление.
Еще на этапе анализа нужно сделать предварительные документы и интерфейс, которые забиваются в прототип. Далее прототип показывается заказчику.
17.Структурный системный анализ. Методология структурного системного анализа sadt (стандарт idef0).
SADT является полной методологией для создания описания систем, основанных на концепции системного моделирования. Эту методологию можно применять как для описания моделей, ориентированных на данные, так и для описания моделей ориентированных на процессы.
Модель SADT представляет собой иерархию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма представляет декомпозицию блока из более общей (родительской) диаграммы.
Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, те же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы.
На SADT-диаграммах не указаны явно ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т.д.
Механизмы (дуги с нижней стороны) показывают средства, с помощью которых осуществляется выполнение функций. Механизм может быть человеком, компьютером или любым другим устройством, которое помогает выполнять данную функцию.
Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть далее детализирована с помощью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм.
Правила SADT включают:
ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);
связность диаграмм (номера блоков);
уникальность меток и наименований (отсутствие повторяющихся имен);
синтаксические правила для графики (блоков и дуг);
разделение входов и управлений (правило определения роли данных).
отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.
