- •Понятие программного обеспечения, классификация программного обеспечения
- •Жизненный цикл по и его стандартизация, процессы жц по, группы процессов жц по
- •Процесс разработки по: основные действия и их содержание
- •Анализ требований к по
- •Проектирование архитектуры по
- •Кодирование и тестирование по
- •Сертификация процессов разработки по, модель cmm
- •Стратегии жизненного цикла по: понятие, виды и их сравнительная характеристика
- •Каскадная модель жизненного цикла по: описание, преимущества и недостатки, критерии применения
- •Процесс макетирования по: его содержание, преимущества и недостатки, критерии применения
- •Недостатки:
- •Инкрементная модель жизненного цикла по: описание, преимущества и недостатки, критерии применения
- •Спиральная модель жизненного цикла по: описание, преимущества и недостатки, критерии применения
- •Rad модель жизненного цикла по: описание, преимущества и недостатки, критерии применения
- •Структурный подход к разработке по: основные принципы и методы
- •Методология idef0: назначение, icom-модель, правила построения диаграммы
- •Методология idef0: назначение, правила построения иерархии диаграмм, критерии завершения и стратегии декомпозиции
- •Методология dfd: назначение, элементы диаграммы и их назначение, правила построения диаграммы
- •Методология dfd: правила построения иерархии диаграмм, спецификации и их содержание
- •Модификация dfd п. Варда и с. Меллора
- •Модификация dfd д. Хетли и и. Пирбхаи
- •Методология idef1x: назначение, сущности и связи: понятие и их обозначения
- •Методология idef1x: назначение, виды и уровни моделей, порядок построения
- •21 Методология idef3: назначение, единица работы, связи и их виды, соединения и их виды
- •Типы связей idef3
- •Типы соединений
- •Виды указателей idef3
- •22 Основные этапы проектирования программных систем и их содержание
- •Информационные потоки процесса синтеза программной системы
- •23 Структурирование программной системы: цели и модели
- •Широковещательная модель
- •Модель, управляемая прерываниями
- •Модульность программной системы: понятие и свойства модуля, цели модульной декомпозиции
- •Затраты на модульность
- •26 Связность модуля: понятие, виды связности и их описание
- •Характеристика связностей модуля
- •27 Сцепление модулей: понятие, виды сцепления и их описание
- •28 Сложность программной системы, основные подходы к ее оценке
- •29 Структурные карты Констайнтайна
- •Элементы структурных карт: а) – модуль; б) – вызов модуля; в) – связь по данным; г) – связь по управлению
- •Типы вызовов модулей
- •30 Метод анализа и проектирования Джексона
- •Соединения между физическими процессами и их моделями
- •31.Объектно-ориентированный подход к разработке по: основные понятия и принципы
- •32.Язык uml: причины появления и история развития языка, структура языка
- •33.Канонические диаграммы языка uml: их виды и типы, рекомендации построения
- •34.Механизмы расширения uml: виды, примеры использования
- •35.Диаграмма вариантов использования: назначение, принципы построения
- •36.Диаграмма классов: назначение, классы, обозначение классов, их атрибутов и операций
- •37.Диаграмма классов: назначение, отношения между классами и их применение
- •38.Диаграмма композитной структуры: композитные классы и их части, принципы построения
- •39.Диаграмма композитной структуры: кооперации и их использование
- •40. Диаграмма пакетов: назначение, пакеты и отношения между ними
- •41.Диаграмма объектов, назначение, объекты и отношения между ними
- •42.Диаграмма последовательности: назначение, линии жизни, прием и передача сообщений между линиями жизни
- •43.Диаграмма последовательности: назначение, комбинированные фрагменты, их виды и использование
- •44.Диаграмма деятельности: назначение, понятие, семантика и обозначение деятельности, действия и дуг
- •45.Диаграмма деятельности: узлы управления, их виды и применение
- •46. Дополнительные элементы диаграммы деятельности: действия приема и передачи сигналов, центральный буфер и хранилище данных
- •Дополнительные элементы диаграммы деятельности: разбиения, регион прерываемой деятельности, обработчик исключений
- •Диаграмма коммуникации: назначение, принципы построения
- •Диаграмма обзора взаимодействия: назначение, принципы построения
- •Когда применяются диаграммы обзора взаимодействия
- •50. Временные диаграммы: назначение, принципы построения
- •51. Диаграмма конечного автомата: назначение, простое и композитное состояния
- •52. Диаграмма конечного автомата: простые и составные переходы, правила срабатывания переходов
- •6.3. Переход
- •6.6. Сложные переходы
- •53. Диаграмма конечного автомата: псевдосостояния, их виды и применение
- •54. Протокольные конечный автомат: назначение, элементы и принципы построения
- •55. Диаграмма компонентов: назначение, компоненты, интерфейсы и порты, соединения и их виды
- •56. Диаграмма развертывания: назначение, узлы, артефакты, соединения и их виды
- •57. Объектно-ориентированные метрики: назначение, связь с принципами ооп
- •58. Объектно-ориентированные метрики: связность по данным
- •59. Объектно-ориентированные метрики: связность по методам
- •60. Объектно-ориентированные метрики: сцепление объектов и локальность данных
- •61. Объектно-ориентированные метрики: набор метрик Чидамбера и Кемерера
- •62. Объектно-ориентированные метрики: набор метрик Лоренца и Кидда
- •63. Объектно-ориентированные метрики: набор метрик Фернандо Аббреу
Подготовительная работа начинается с выбора модели ЖЦ ПО, соответствующей масштабу, значимости и сложности проекта.
Анализ требований к системе подразумевает определение ее функциональных возможностей, пользовательских требований, требований к надежности и безопасности, к внешним интерфейсам и т.д.
Проектирование архитектуры системы на высоком уровне заключается в определении компонентов ее оборудования, ПО и операций, выполняемых эксплуатирующим систему персоналом.
Анализ требований к по
Проектирование архитектуры по
Детальное проектирование ПО
Кодирование и тестирование по
Интеграция ПО предусматривает сборку разработанных компонентов ПО в соответствии с планом интеграции и тестирование агрегированных компонентов.
Квалификационное тестирование ПО проводится разработчиком в присутствии заказчика (по возможности) для демонстрации того, что ПО удовлетворяет своим спецификациям и готово к использованию в условиях эксплуатации.
Интеграция системы заключается в сборке всех ее компонентов, включая ПО и оборудование.
После интеграции система, в свою очередь, подвергается квалификационному тестированию на соответствие совокупности требований к ней.
Установка ПО осуществляется разработчиком в соответствии с планом в той среде и на том оборудовании, которые предусмотрены договором.
Приемка ПО предусматривает оценку результатов квалификационного тестирования ПО и системы и документирование результатов оценки, которые проводятся заказчиком с помощью разработчика. Разработчик выполняет окончательную передачу ПО заказчику в соответствии с договором, обеспечивая при этом необходимое обучение и поддержку.
Сертификация процессов разработки по, модель cmm
Гарантия качества процессов разработки программных продуктов является весьма значимой в современных условиях. Такую гарантию дают сертификаты качества процесса, подтверждающие его соответствие принятым международным стандартам. Наиболее авторитетными являются модели стандартов ISO 9001:2000, ISO/IEC 15504 и модель зрелости процесса разработки ПО (Capability Maturity Model – CMM).
Основным понятием модели CMM является зрелость процессов (Software process maturity). Зрелость процессов – это степень их управляемости, контролируемости и эффективности. Повышение технологической зрелости означает потенциальную возможность возрастания устойчивости процессов и указывает на степень эффективности и согласованности использования процессов создания и сопровождения ПО в рамках всей организации.
В модели CMM выделены пять уровней технологической зрелости, которые в принципе могут быть достигнуты компанией:
1. Начальный уровень означает, что процесс в компании не формализован. Он не может строго планироваться и отслеживаться, его успех носит случайный характер. Результат работы целиком и полностью зависит от личностных качеств отдельных сотрудников, увольнение которых приводит к остановке проекта.
2. На повторяемом уровне внедряются формальные процедуры для выполнения основных элементов процесса конструирования. Результаты выполнения процесса соответствуют заданным требованиям и стандартам. Выполнение проекта на этом уровне планируется и контролируется, а применяемые для этих целей средства дают возможность повторения ранее достигнутых успехов.
3. Определенный уровень требует, чтобы все элементы процесса были определены, стандартизированы и задокументированы. На этом уровне все процессы планируются и управляются на основе единого стандарта компании. Качество разрабатываемого ПО уже не зависит от способностей отдельных личностей.
4. На управляемом уровне в компании принимаются количественные показатели качества как программных продуктов, так и технологических процессов. Это обеспечивает более точное планирование проекта и контроль качества его результатов. Основное отличие от предыдущего уровня состоит в более объективной, количественной оценке продукта и процесса.
5. На высшем, оптимизирующем, уровне главной задачей компании становится постоянное улучшение и повышение эффективности существующих процессов, ввод новых технологий. Технология создания и сопровождения программных продуктов планомерно и последовательно совершенствуется.