- •Раздел 9 организация проектирования и разработки программного обеспечения
- •1.Методологии разработки программного обеспечения – каскадная, спиральная, инкрементальная. Их сущность и области применения.
- •2.Методологии Rational Unified Process: сущность и области применения.
- •3.Гибкие методологии разработки программного обеспечения. Их сущность, примеры и области применения.
- •4.Экстремальное программирование: сущность и области применения
- •5.Методология scrum: сущность и области применения.
- •6.Стандарты в описании процессов жизненного цикла разработки программного обеспечения. Стандарты исо в области системной и программной инженерии. Корпоративные стандарты.
- •Стандарт гост 34.601-90
- •Предпосылки стандартизации
- •7.Управление конфигурацией: содержание процесса управления конфигурацией, организация информационной поддержки процесса управления конфигурацией
- •Базовые концепции и элементы
- •Основы управления конфигурацией
- •8.Аудит проекта разработки по. Место аудита в общей структуре управления проектом. Роль стандартов в процессе аудита
- •9.Стандарт CobiT и его роль в управлении и аудите ит.
- •10.Сертификация и лицензирование в проекте разработки программного обеспечения. Ответственность за использование нелицензионного программного обеспечения
- •Лицензирование программного обеспечения
- •Раздел 1
- •Раздел 2 анализ и моделирование на uml
- •Раздел 3 базы данных
- •Раздел 4 управление проектами
- •Раздел 5 операционные системы, среды и оболочки
- •Раздел 6 проектная документация
- •Раздел 7 система менеджемента качества
- •Раздел 8 финансовый менеджемент
- •Раздел 9 организация проектирования и разработки программного обеспечения
- •1.Методологии разработки программного обеспечения – каскадная, спиральная, инкрементальная. Их сущность и области применения.
Базовые концепции и элементы
Нельзя сказать, что никто до этого не использовал таких методов работы. Разработка и раньше велась параллельно с документированием. Ревизии документов проводились и раньше. Тестирование и испытания продукции на предмет соответствия требованиям проводились и до этого. Отчетность использовалась в проектах и раньше. Основатели дисциплины управления конфигурацией сделали другое – они собрали вместе, упорядочили и дали названия всем этим техникам, используемым при разработке, так что в итоге получилась отдельная дисциплина – управление конфигурацией.
Во время формирования дисциплины управления конфигурацией в ней были воплощены следующие важные концепции:
Документы создаются для описания продукта и являются средством управления конфигурацией продукта.
Изменения в продукте контролируются посредством контроля изменений в документации.
Изменения в продукте не производятся до тех пор, пока они не сделаны в документации.
До того, как быть реализованными в документации и продукте, изменения должны быть формально утверждены.
Все изменения должны отслеживаться.
Конфигурационные объекты (продукты), документы и их версии нумеруются и именуются единообразно и недвусмысленно (или уникально).
Ведется отчетность о состоянии изменений, документов и продуктов.
Каждый документ периодически сравнивается с соответствующим ему документом верхнего уровня на предмет выявления несоответствий.
Продукт в целом сравнивается со своим описанием (конфигурационной идентификацией) и должен этому описанию соответствовать.
Используя введенную выше терминологию управления конфигурацией, эти концепции были сгруппированы в следующие четыре элемента управления конфигурацией:
Конфигурационная идентификация (концепция 1)
Контроль конфигурации (концепции 2, 3, 4, 5, 6)
Учет состояния конфигурации (концепция 7)
Ревизия и аудит конфигурации (концепции 8 и 9)
Такова была первоначальная концепция управления конфигурацией как для программных средств (software), так и для оборудования (hardware). Представленную здесь первоначальную терминологию дисциплины управления конфигурацией можно также найти в стандарте IEEE-STD-610. Далее будут рассмотрены стандарты, определяющие основные положения и терминологию управления конфигурацией.
Недостаточно четкое понимание терминологии управления конфигурацией, происходящее обычно из-за отсутствия формального обучения этой дисциплине, зачастую приводит к смещению концептуальных понятий и путанице в основополагающих принципах УК.
Так, например, основной элемент управления конфигурацией «конфигурационная идентификация» зачастую воспринимается в значении наименования или нумерации документа или продукта, что должно соответствовать понятию «идентификации документа» или «идентификации продукта». В то время как понятие «конфигурация» не относится к документу или продукту. Это понятие относится к содержанию документов, обозначая содержание технической документации, описывающей продукт. Кстати говоря, правила наименования и нумерации документов и продуктов относятся к следующему элементу УК – «контролю конфигурации», и называются «соглашениемпо наименованию и нумерации».