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