- •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 Планирование рисков. Мониторинг рисков
4 Структура затрат на создание, модернизацию по различных типов
Структура стоимости ПО существенно зависит от типа ПО, применяемых методов его разработки и … метода оценки. Так, многие авторы отмечают высокую долю стоимости этапа сопровождения. Для некоторых типов ПО она может составлять 60 и более процентов от общей стоимости. Между тем, этап сопровождения включает выполнение двух видов работ: исправление ошибок в программе (несоответствий первоначальным требованиям) и внесение изменений в программу (добавление новых требований). При другом подходе к оценке можно считать, что этап сопровождения на стоит оценивать отдельно, т.к. исправление ошибок можно отнести к продолжению тестирования, а внесение изменений – к новому проекту.
Типовое распределение стоимости между основными этапами (без сопровождения) выглядит следующим образом:
• 15% - спецификация – формулировка требований и условий разработки
• 25% - проектирование – разработка и верификация проекта
• 20% - разработка – кодирование и тестирование компонент
• 40% - интеграция и тестирование – объединение и сборочное тестирование продукта
Отклонения от этой схемы в зависимости от типа ПО выглядят следующим образом:
Для коробочного ПО характерна более высокая доля тестирования за счет сокращения прежде всего доли спецификации (до 5%)
Распределение стоимости заказного ПО зависит от его сложности. При сложном ПО также возрастает доля интеграции и тестирования, но за счет сокращения доли проектирования и разработки Доля спецификаций может возрастать. Сокращение доли проектирования и разработки достигается за счет применения опробованных проектных решений и повторного использования готовых компонент.
Применение опробованных решений и готовых компонент при создании коробочных продуктов позволяет повысить качество и сократить сроки разработки.
Стоимость модернизации общих ПП оценке практически не поддается, поэтому во многих случаях производится небольшая формальная модернизация и с началом реализации ПО начинается работа над след версией.
5 Характеристики качественного по
Кроме функциональных возможностей присущих ПП по определению, эти продукты обладают и другими показателями, характеризующими их качества. Они отображают поведение программы во время выполнения ею своих действий, структуру и организацию исходного кода программы, ее документированность.
- удобство сопровождения – ПО должно быть таким, чтобы существовала возможность его усовершенствования в ответ на измененные требования заказчика или пользователя.
- надежность – определяется рядом характеристик таких как безотказность, защищенность и безопасность.
- эффективность – работа ПО не должна приводить к расточительному расходованию системных ресурсов. Этот параметр описывается след характеристиками:
1.скорость выполнения
2. используемое процессорное время
3. объем требуемой памяти
- удобство в использовании – ПО должно быть удобным в эксплуатации и не требовать чрезмерного напряжения усилий пользователя того уровня, на которого оно рассчитано.