Основы Программной Инженерии (по swebok) Введение Программная инженерия как дисциплина swebok руководство
 Скачать 3.21 Mb.
|
|
Модели жизненного цикла программного обеспечения Одним из ключевых понятий управления проектами, в том числе в приложении к индустрии программного обеспечения, является жизненный цикл проекта (Project Lifecycle Management - PLM). Известный эксперт по управлению высокотехнологичными проетами Арчибальд так определяет жизненный цикл проекта [Арчибальд Р., 2003, с.58-59] [Арчибальд Р., 2005]: “Жизненный цикл проекта имеет определенные начальную и конечную точки, привязанные к временной шкале. Проект в своем естественном развитии проходит ряд отдельных фаз. Жизненный цикл проекта включает все фазы от момента инициации до момента завершения. Переходы от одного этапа к другому редко четко определены, за исключением тех случаев, когда они формально разделяются принятием предложения или получением разрешения на продолжение работы. Однако, в начале концептуальной фазы часто возникают сложности с точным определением момента, когда работу можно уже идентифицировать как проект (в терминах управления проектами), особенно если речь идет о разработке нового продукта или новой услуги. Существует общее соглашение о выделении четырех обобщенных фаз жизненного цикла (в скобках приведены используемые в различных источниках альтернативные термины): - концепция (инициация, идентификация, отбор) - определение (анализ) - выполнение (практическая реализация или внедрение, производство и развертывание, проектирование или конструирование, сдача в эксплуатацию, инсталляция, тестирование и т.п.) - закрытие (завершение, включая оценивание после завершения) Однако, эти фазы столь широки, что … необходимы конкретные определения, быть может пяти-десяти основных фаз для каждой категории и подкатегории проекта, обычно с несколькими подфазами, выделяемыми внутри каждой из этих фаз. …Нередко можно наблюдать частичное совмещение или одновременное выполнение фаз проекта, называемое “быстрым проходом” в строительных и инжиниринговых проектах и “параллелизмом” – в военных и аэрокосмических. Это усложняет планирование проекта и координацию усилий его участников, а также делает более важной роль менеджера проектов.” В общем случае, жизненный цикл определяется моделью и описывается в форме методологии (метода). Модель или парадигма жизненного цикла определяет концептуальный взгляд на организацию жизненного цикла и, часто, основные фазы жизненного цикла и принципы перехода между ними. Методология (метод) задает комплекс работ, их детальное содержание и ролевую ответственность специалистов на всех этапах выбранной модели жизненного цикла, обычно определяет и саму модель, а также рекомендует практики (best practices), позволяющие максимально эффективно воспользоваться соответствующей методологией и ее моделью. В индустрии программного обеспечения можно (так как это уже конкретная область приложения концепций и практик проектного управления) и необходимо (для обеспечения возможности управления) более четкое разграничение фаз проекта (что не подразумевает их линейного и последовательного выполнения). Ниже приведены определения <модели> жизненного цикла программной системы, даваемые, например, в различных вариантах стандартов ГОСТ: - Модель жизненного цикла - структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее использования [ГОСТ 12207, 1999]. - Жизненный цикл автоматизированной системы (АС) - совокупность взаимосвязанных процессов создания и последовательного изменения состояния АС, от формирования исходных требований к ней до окончания эксплуатации и утилизации комплекса средств автоматизации АС [ГОСТ 34, 1990]. Один из них - ГОСТ Р ИСО/МЭК 12207 является переводом международного стандарта ISO/IEC 12207, на основе которого, в свою очередь, создан соответствующий стандарт IEEE 12207. Второй – в рамках семейства ГОСТ 34 – разрабатывался в СССР самостоятельно, как стандарт на содержание и оформление документов на программные системы в рамках Единой системы программной документации (ЕСПД) и Единой системы конструкторской документации (ЕСКД). В последние годы, акцент делается на стандарты ГОСТ, соответствующие международным стандартам. В то же время, 34-я серия является важным дополнительным источником информации для разработки и стандартизации внутрикорпоративных документов и формирования целостного понимания и видения концепций жизненного цикла в области программного обеспечения. В определённом контексте, “модель” и “методология” могут использоваться взаимозаменяемым образом, например, когда мы обсуждаем разграничение фаз проекта. Говоря “жизненный цикл” мы, в первую очередь, подразумеваем “модель жизненного цикла”. Несмотря на данное в стандартах 12207 определение модели жизненного цикла, все же, модель чаще подразумевает именно общий принцип организации жизненного цикла, чем детализацию соответствующих работ. Соответственно, определение и выбор модели, в первую очередь, касается вопросов определенности и стабильности требований, жесткости и детализированности плана работ, а также частоты сборки работающих версий создаваемой программной системы. Скотт Амблер (Scott W. Ambler) [Ambler, 2005], автор концепций и практик гибкого моделирования (Agile Modeling) и Enterprise Unified Process (расширение Rational Unified Process), предлагает следующие уровни жизненного цикла, определяемые соответствующим содержанием работ (см. рис.1): Жизненный цикл разработки программного обеспечения – проектная деятельность по разработке и развертыванию программных систем Жизненный цикл программной системы – включает разработку, развертывание, поддержку и сопровождение Жизненный цикл информационных технологий (ИТ) – включает всю деятельность ИТ-департамента Жизненный цикл организации/бизнеса – охватывает всю деятельность организации в целом Рисунок 1. Содержание четырех категорий жизненного цикла по Амблеру(используется с разрешения автора) [Ambler, 2005] В данном контексте, SWEBOK описывает области знаний жизненного цикла системы и жизненного цикла разработки программного обеспечения. В свою очередь, как упоминается в SWEBOK, одним из фундаментальных взглядов на жизненный цикл является стандарт процессов жизненного цикла ISO/IEC, IEEE, ГОСТ Р ИСО/МЭК 12207. Стандарт 12207: Процессы жизненного цикла программного обеспечения В 1997 году Международная Организация по Стандартизации - ИСО (International Organization for Standardization - ISO) и Международная Электротехническая Комиссия - МЭК (International Electrotechnical Commission - IEC) создали Совместный Технический Комитет по Информационным Технологиям - Joint Technical Committee (JTC1) on Information Technology. Содержание работ JTC1 определено как “стандартизация в области систем и оборудования информационных технологий (включая микропроцессорные системы)”. В 1989 году этот комитет инициировал разработку стандарта ISO/IEC 12207, создав для этого подкомитет SC7 (SuСommittee 7) по программной инженерии. Соответствующий стандарт впервые был опубликован 1-го августа 1995 года под заголовком “Software Life Cycle Processes” – “Процессы жизненного цикла программного обеспечения”. Национальный стандарт [ГОСТ 12207, 1999] получил название “Процессы жизненного цикла программных средств”. Цель разработки данного стандарта была определена как создание общего фреймворка по организации жизненного цикла программного обеспечения для формирования общего понимания жизненного цикла ПО всеми заинтересованными сторонами и участниками процесса разработки приобретения, поставки, эксплуатации, поддержки и сопровождения программных систем, а также возможности управления, контроля и совершенствования процессов жизненного цикла. Данный стандарт определяет жизненный цикл как структуру декомпозиции работ. Детализация, техники и метрики проведения работ – вопрос программной инженерии. Организация последовательности работ – модель жизненного цикла. Совокупность моделей, процессов, техник и организации проектной группы задаются методологией. В частности, выбор и применение метрик оценки качества программной системы и процессов находятся за рамками стандарта 12207, а концепция совершенствования процессов рассматривается в стандарте ISO/IEC 15504 “Information Technology - Software Process Assessment” (“Оценка процессов <в области> программного обеспечения”). Необходимо отметить заложенные в стандарте ключевые концепции рассмотрения жизненного цикла программных систем. Организация стандарта и архитектура жизненного цикла Стандарт определяет область его применения, дает ряд важных определений (таких, как заказчик, разработчик, договор, оценка, выпуск – релиз, программный продукт, аттестация и т.п.), процессы жизненного цикла и включает ряд примечаний по процессу и вопросам адаптации стандарта. Стандарт описывает 17 процессов жизненного цикла, распределенных по трем категориям – группам процессов (названия представлены с указанием номеров разделов стандарта, следуя определениям на русском и английском языке, определяемыми [ГОСТ 12207, 1999] и оригинальной версией ISO/IEC 12207, соответственно): Основные процессы жизненного цикла - Primary Processes 5.1 Заказ - Acqusition 5.2 Поставка - Supply 5.3 Разработка - Development 5.4 Эксплуатация - Operation 5.5 Сопровождение - Maintenance Вспомогательные процессы жизненного цикла – Supporting Processes 6.1 Документирование - Documentation 6.2 Управление конфигурацией – Configuration Management 6.3 Обеспечение качества – Quality Assurance 6.4 Верификация - Verification 6.5 Аттестация - Validation 6.6 Совместный анализ – Joint Review 6.7 Аудит - Audit 6.8 Решение проблем – Problem Resolution Организационные процессы жизненного цикла – Organizational Processes 7.1 Управление - Management 7.2 Создание инфраструктуры - Infrastructure 7.3 Усовершенствование - Improvement 7.4 Обучение - Training Стандарт определяет высокоуровневую архитектуру жизненного цикла. Жизненный цикл начинается с идеи или потребности, которую необходимо удовлетворить с использованием программных средств (может быть и не только их). Архитектура строится как набор процессов и взаимных связей между ними. Например, основные процессы жизненного цикла обращаются к вспомогательным процессам, в то время, как организационные процессы действуют на всем протяжении жизненного цикла и связаны с основными процессами. Дерево процессов жизненного цикла представляет собой структуру декомпозиции жизненного цикла на соответствующие процессы (группы процессов). Декомпозиция процессов строится на основе двух важнейших принципов , определяющих правила разбиения (partitioning) жизненного цикла на составляющие процессы. Эти принципы: Модульность задачи в процессе являются функционально связанными; связь между процессами – минимальна; если функция используется более, чем одним процессом, она сама является процессом; если Процесс Y используется Процессом X и только им, значит Процесс Y принадлежит (является его частью или его задачей) Процессу X, за исключением случаев потенциального использования Процесса Y в других процессах в будущем. Ответственность каждый процесс находится под ответственностью конкретного лица (управляется и/или контролируется им), определенного для заданного жизненного цикла, например, в виде роли в проектной команде; функция, чьи части находятся в компетенции различных лиц, не может рассматриваться как самостоятельный процесс. Общая иерархия (декомпозиция) составных элементов жизненного цикла выглядит следующим образом: группа процессов ** процессы *** работы **** задачи В общем случае, разбиение процесса базируется на широко распространенном PDCA-цикле: “P” – Plan – Планирование “D” – Do – Выполнение “C” – Check – Проверка “A” – Act – Реакция (действие) Рассмотрим вкратце, какие работы составляют процессы жизненного цикла, помня, что полное определение работ, как и определение составляющих их задач, дано непосредственно в стандарте. Ниже приведен краткий обзор основных процессов жизненного цикла, явно демонстрирующий связь вопросов, касающихся непосредственно самой программной системы, с системными аспектами ее функционирования и обеспечения ее эксплуатации. Основные процессы жизненного цикла Приобретение (5.1) Процесс приобретения (как его называют в ГОСТ – “заказа”) определяет работы и задачи заказчика, приобретающего программное обеспечение или услуги, связанные с ПО, на основе контрактных отношений. Процесс приобретения состоит из следующих работ (названия ГОСТ 12207 даны в скобках, если предлагают другой перевод названий работ оригинального стандарта): Inititation – инициирование (подготовка) Request-for-proposal preparation – подготовка запроса на предложение (подготовка заявки на подряд) Contract preparation and update –подготовка и корректировка договора Supplier monitoring – мониторинг поставщика (надзор за поставщиком) Acceptance and completion – приемка и завершение (приемка и закрытие договора) Все работы проводятся в рамках проектного подхода. Поставка (5.2) Процесс поставки, в свою очередь, определяет работы и задачи поставщика. Работы также проводятся с использованием проектного подхода. Процесс включает следующие работы: Inititation – инициирование (подготовка) Preparation of response – подготовка предложения (подготовка ответа) Contract – разработка контракта (подготовка договора) Planning - планирование Execution and control – выполнение и контроль Review and evaluation –проверка и оценка Delivery and completion – поставка и завершение (поставка и закрытие договора) Разработка (5.3) Процесс разработки определяет работы и задачи разработчика. Процесс состоит из следующих работ: Process implementation – определение процесса (подготовка процесса) System requirements analysis – анализ системных требований (анализ требований к системе) System design – проектирование системы (проектирование системной архитектуры) Software requirements analysis – анализ программных требований (анализ требований к программным средствам) Software architectural design – проектирование программной архитектуры Software detailed design – детальное проектирование программной системы (техническое проектирование программных средств) Software coding and testing – кодирование и тестирование (программирование и тестирование программных средств) Software integration – интеграция программной системы (сборка программных средств) Software qualification testing – квалификационные испытания программных средств System integration – интеграция системы в целом (сборка системы) System qualification testing – квалификационные испытания системы Software installation – установка (ввод в действие) Software acceptance support – обеспечение приемки программных средств Стандарт отмечает, что работы проводятся с использованием проектного подхода и могут пересекаться по времени, т.е. проводиться одновременно или с наложением, а также могут предполагать рекурсию и разбиение на итерации. Эксплуатация (5.4) Процесс разработки определяет работы и задачи оператора службы поддержки. Процесс включает следующие работы: Process implementation – определение процесса (подготовка процесса) Operational testing – операционное тестирование (эксплуатационные испытания) System operation – эксплуатация системы User support – поддержка пользователя Сопровождение (5.5) Процесс разработки определяет работы и задачи, проводимые специалистами службы сопровождения. Процесс включает следующие работы: Process implementation – определение процесса (подготовка процесса) Problem and modification analysis – анализ проблем и изменений Modification implementation – внесение изменений Maintenance review/acceptance – проверка и приемка при сопровождении Migration – миграция (перенос) Software retirement – вывод программной системы из эксплуатации (снятие с эксплуатации) Важно понимать, что стандарт 12207 не определяет последовательность и разбиение выполнения процессов во времени, адресуя этот вопрос также работам по адаптации стандарта к конкретным условиям и окружению и применению выбранных моделей, практик, техник и т.п. Адаптация стандарта Адаптация стандарта* подразумевает применение требований стандарта к конкретному проекту или проектам, например, в рамках создания внутрикорпоративных регламентов ведения проектов программного обеспечения. Адаптация включает следующие виды работ: Определение исходной информации для адаптации стандарта Определение условий выполнения проекта Отбор процессов, работ и задач, используемых в проекте или соответствующих регламентах Документирование требований, решений и процессов, связанных с адаптацией и полученных в ее результате Адаптация также подразумевает выбор модели (или комбинации моделей) жизненного цикла, а также применение соответствующих методологий, детализирующих процедуры выполнения процессов, работ и задач в рамках заданных границ (содержания) жизненного цикла программного обеспечения и организационной структуры и ролевой ответственности в конкретной организации (ее подразделении) и/или в проектной группе. Необходимо отметить, что существует еще один стандарт жизненного цикла - ISO/IEC 15288 (выпущен в 2002 году), фокусирующийся на вопросах организации процессов жизненного цикла системного уровня (Life Cycle Processes – System) и включающий специальный процесс - “Tailoring”, т.е. настройку, адаптацию жизненного цикла к конкретным требованиям и ограничениям, существующим или принятым в конкретной организации/подразделении или для заданного проекта. |