Области знаний программной инженерии и стандарты ЖЦ программного обеспечения

1.1.2. Проектирование ПО (Software design)

Проектирование ПО - это процесс определения архитектуры, компонентов, интерфейсов, других характеристик системы и конечного состава программного продукта. Область знаний "Проектирование ПО (Software Design)" состоит из следующих разделов:

Базовая концепция проектирования ПО - это методология проектирования архитектуры с помощью разных методов (объектного, компонентного и др.), процессы ЖЦ (стандарт ISO/IEC 12207) и техники - декомпозиция, абстракция, инкапсуляция и др. На начальных стадиях проектирования предметная область декомпозируется на отдельные объекты (при объектно-ориентированном проектировании) или на компоненты (при компонентном проектировании). Для представления архитектуры программного обеспечения выбираются соответствующие артефакты (нотации, диаграммы, блок-схемы и методы).

К ключевым вопросам проектирования ПО относятся: декомпозиция программ на функциональные компоненты для независимого и параллельного их выполнения, принципы распределения компонентов в среде выполнения и их взаимодействия между собой, механизмы обеспечения качества и живучести системы и др.

При проектировании архитектуры ПО используется архитектурный стиль проектирования, основанный на определении основных элементов структуры - подсистем, компонентов и связей между ними.

Архитектура проекта - высокоуровневое представление структуры системы и спецификация ее компонентов. Архитектура определяет логику отдельных компонентов системы настолько детально, насколько это необходимо для написания кода, а также определяет связи между компонентами. Существуют и другие виды представления структур, основанные на проектировании образцов, шаблонов, семейств программ и каркасов программных сред.

Одним из важнейших инструментов проектирования архитектуры является паттерн - типовой конструктивный элемент ПО, который задает взаимодействие объектов (компонентов) проектируемой системы, а также роли и ответственности исполнителей. Основным языком описания этого элемента является UML. Он может быть структурным, включающим типовые композиции структур из объектов и классов, объектов, связей и др.; поведенческим, определяющим схемы взаимодействия классов объектов и их поведение диаграммами активностей, взаимодействия, потоков управления и др.; порождающим, отображающим типовые схемы распределения ролей экземпляров объектов и способы динамической генерации структур объектов и классов.

Анализ и оценка качества проектирования ПО включает мероприятия по анализу сформулированных в требованиях атрибутов качества, оценки различных аспектов ПО - количества функций, структура ПО, качества проектирования с помощью формальных метрик (функционально-ориентированных, структурных и объектно-ориентированных), а также проведения качественного анализа результатов проектирования путем статического анализа, моделирования и прототипирования.

Нотации проектирования позволяют представить описание объекта (элемента) ПО и его структуру, а также поведение системы. Существует два типа нотаций: структурные, поведенческие и множество различных их представлений.

Структурные нотации - это структурное, блок-схемное или текстовое представление аспектов проектирования структуры ПО из объектов, компонентов, их интерфейсов и взаимосвязей. К нотациям относятся формальные языки спецификаций и проектирования: ADL (Architecture Description Language), UML (Unified Modeling Language), ERD (Entity-Relation Diagrams), IDL (Interface Description Language), Use Case Driven и др. Нотации включают языки описания

архитектуры и интерфейса, диаграммы классов и объектов, диаграммы сущность-связь, конфигурации компонентов, схем развертывания, а также структурные диаграммы, задающие в наглядном виде операторы цикла, ветвления, выбора и последовательности.

Поведенческие нотации отражают динамический аспект поведения систем и их компонентов. Таким нотациям соответствуют диаграммы потоков данных (Data Flow), таблиц принятия решений (Decision Tables), деятельности (Activity), кооперации (Collaboration), последовательности (Sequence), пред- и постусловия (Pre-Post Conditions), формальные языки спецификации (Z, VDM, RAISE), языки проектирования PDL и др.

Стратегия и методы проектирования ПО.К стратегиям относятся: проектирование снизу-вверх, сверху-вниз, абстрагирование, использование паттернов и др. методы - это функционально-ориентированные, структурные, которые базируются на структурном анализе, структурных картах, диаграммах потоков данных (Dataflow) и др. Они ориентированы на идентификацию функций и их уточнение сверху-вниз, после чего уточняются диаграммы потоков данных и проводится описание процессов.

В объектно-ориентированном проектировании ключевую роль играет наследование, полиморфизм и инкапсуляция, а также абстрактные структуры данных и отображение объектов. Подходы, ориентированные на структуры данных, базируются на методе Джексона [1.8] и используются для задания входных и выходных данных структурными диаграммами. Метод UML предназначен для сценарного моделирования проекта [1.19] в наглядном диаграммном виде. Компонентное проектирование ориентировано на использование готовых компонентов (reusing), их интерфейсов и интеграцию для формирования конфигурации, служащей основой развертывания компонентного ПО и взаимодействия компонентов в операционной среде.

Формальные методы описания программ основываются на спецификациях, аксиомах, описаниях некоторых условий, называемых предварительными (предусловиями), утверждениях и постусловиях, определяющих заключительное условие получения правильного результата программой. Спецификация является формальным описанием функций и данных программы, с которыми эти функции оперируют. Различают входные и выходные параметры функции, а также данные, которые не привязаны к реализации и определяют интерфейс с другими функциями. По формальным спецификациям,

условиям и утверждениям выполняется доказательство правильности программы

1.1.3. Конструирование ПО (Software Construction)

Конструирование ПО - создание работающего ПО с привлечением методов верификации, кодирования и тестирования компонентов. К инструментам конструирования ПО отнесены языки программирования и конструирования, а также программные методы и инструментальные системы (компиляторы, СУБД, генераторы отчетов, системы управления версиями, конфигурацией, тестированием и др.). К формальным средствам описания процесса конструирования ПО, взаимосвязей между человеком и компьютером и с учетом среды окружения отнесены, например, структурные диаграммы Джексона.

Область знаний "Конструирование ПО (Software Construction)" включает следующие разделы:

Снижения сложности - это минимизация, уменьшение и локализация сложности конструирования.

Минимизация сложности определяется ограниченными возможностями исполнителей обрабатывать сложные структуры и большие объемы информации на протяжении длительного периода времени. Минимизация сложности достигается, в частности, использованием в процессе конструирования модулей и других более простых элементов а также рекомендациями стандартов.

Уменьшение сложности в конструировании ПО достигается при создании простого и легко читаемого кода для придания большей значимости этого кода, простоте тестирования, производительности и удовлетворению заданных критериев. Это влияет на функциональность, характеристики и ограничения проекта. Потребность в уменьшении сложности влияет на все аспекты конструирования и особенно критична для процессов верификации (проверки) и тестирования результатов конструирования элементов ПС.

Локализация сложности - это способ конструирования с применением объектно-ориентированного подхода, который лимитирует интерфейс объектов, упрощает их взаимодействие, также проверку правильности самих объектов и связей между ними. Локализация упрощает внесение изменений, связанных с обнаруженными ошибками в коде, либо источником ошибок является среда, в которой выполняется код.

Предупреждение отклонений от стиля.Для решения различных задач конструирования применяются разные стили конструирования (лингвистический, формальный, визуальный).

Лингвистический стиль основан на использовании словесных инструкций и выражений для представлений отдельных элементов (конструкций) программ. Он используется при конструировании несложных конструкций и приводится к виду традиционных функций и процедур, логическому и функциональному их программированию и др.

Формальный стиль используется для точного, однозначного и формального определения компонентов системы. В результате его применения обеспечивается конструирование сложных систем с минимальным количеством ошибок, которые могут возникнуть в связи с неоднозначностью определений или обобщений при конструировании ПО неформальными методами.

Визуальный стиль является наиболее универсальным стилем конструирования ПО, он позволяет разработчикам проекта представлять конструируемый элемент в наглядном виде. Визуальный язык проектирования UML представляет разработчику набор удобных диаграмм для задания статической и динамической структуры ПО [1.17]. При применении визуального стиля конструирования создается текстовое и диаграммное описание конструктивных элементов ПО, которое выводится на экран дисплея не только для их наглядного представления, но и корректировки.

Структуризация проверок предполагает, что построение ПС должно проводиться таким образом, чтобы сама система помогала вести поиск ошибок, дефектов и причин сбоев при применении различных методов проверки, как на стадии независимого тестирования (например, инженерами-тестировщиками), так и в процессе эксплуатации, когда особенно важно быстрое обнаружение и исправление возникающих ошибок. Структуризации проверок способствуют обзор, инспектирование, просмотр, модульное тестирование, применение автоматизированных средств тестирования и др.

Использование внешних стандартов. Конструирование ПО зависит от применения внешних стандартов, связанных с языками программирования, инструментальными средствами и интерфейсами. При конструировании должен быть определен достаточный и полный набор стандартов для руководства и обеспечения координации между определенными видами деятельности, группами операций, минимизации сложности, внесения изменений, анализа рисков и др.

Иными словами, внешние и внутренние стандарты должны определить общие правила работы членов проектной команды с учетом процессов ЖЦ. Такими стандартами являются: языки программирования (например, Java Language Specification, С++), интерфейсы ЯП и прикладные интерфейсы платформ Windows и др. При конструировании используются стандарты: ЯП (Ада 95, С++ и др.), языков описания данных (XML, SQL и др.), средств коммуникации (COM, CORBA и др.), интерфейсных языков (POSIX, IDL, APL) [1.18], сценарии UML [1.17] и др.

Данная область пополнилась новым разделом (SWEBOK, 2004 г.), описываемым ниже.

Управление конструированием - это управление процессом конструирования ПО, которое базируется на моделях конструирования, планировании и внесении изменений.

Модели конструирования включают набор операций, последовательность действий и результатов. Виды моделей определяются стандартом ЖЦ, методологиями и практиками. Некоторые стандарты ЖЦ по своей природе ориентированы на конструирование, например, экстремальное программирование (XP - eXtreme Programming). Конструирование с помощью моделирования осуществляется в рациональном унифицированном процессе - RUP (Rational Unified Process) [1.19].

Планирование состоит в определении порядка операций и уровня выполнения заданных условий в процессе конструкторской деятельности. Определяется модель ЖЦ, включающая задачи и действия по созданию компонентов, а также по их проверке, включая достижение показателей качества на этапах ЖЦ. Исполнители распределяются по процессам ЖЦ и выполняют соответствующие задачи по реализации промежуточного продукта. Затем проводится измерение разных аспектов конструирования, например, количественная оценка объема кода, оценка степени использования reuse, вычисление вероятности появления дефектов и оценка количественных показателей качества ПО.

Внесение изменений связано с ошибками, выявленными путем разного рода проверок и тестирований, оно проводится с целью сохранения функциональной целостности системы. В случае обнаружения ошибок на этапе сопровождения принимается решение об изменении кода путем исправления обнаруженных ошибок или внесения изменений в требования к ПО.

1.1.4. Тестирование ПО (Software Testing)

Тестирование ПО - это процесс проверки готовой программы в статике (просмотры, инспекции, отладки исходного кода) и в динамике путем прогона конечного набора тестовых данных, проверяющих разные пути выполнения программы и сравнении полученных результатов с заранее запланированными.

Существует две формы проверки кода - модульное и интеграционное. При этом используются стандарты (IEEE 829-1996 и IEEE 1008-1987) проверки и тестирования модулей ПО. Затем проводится интеграционное тестирование модулей системы и их интерфейсов в динамике выполнения. В процессе разных видов проверок собираются данные об ошибках, дефектах, отказах и т.п. и оформляется соответствующая документация (таблицы типов ошибок, частота и время появления отказов и др.). Данные, собранные при отладке, просмотрах, инспекции и тестировании, используются для оценки характеристик качества готового ПО, например, атрибутов показателя надежности - интенсивность отказов, количество ошибок и др.

Область знаний "Тестирование ПО (Software Testing)" включает следующие разделы:

Данная область знаний SWEBOK представляет разработчику методы проверки правильности ПО: верификация, валидация, тестирование. Определяются типы, уровни и техники тестирования ПО, методы планирования процесса тестирования и разработки тестовых наборов данных для прогонки ПО в режиме испытания конкретного модуля или системы в целом, с последующим измерением результатов тестирования.

Основная концепция тестирования описывает базовые термины, ключевые проблемы и их связь с другими областями знаний. Тестирование - это процесс проверки правильности программы в динамике ее выполнения на тестовых данных. При тестировании выявляются недостатки: отказы (faults) и дефекты (defects) как причины нарушения работы программы, сбои (failures) как нежелательные ситуации, ошибки (errors), как последствия сбоев и др. Базовым понятием тестирования является тест, который выполняется в заданных условиях и на заданных наборах данных. Тестирование считается успешным, если найден дефект или ошибка, и они сразу устраняются. Степень тестируемости определяется критерием покрытия системы тестами, проверки всех возможных путей выполнения алгоритмов программ и вероятности статического предположения того, что при тестировании может появиться сбой или ошибочная ситуация в системе.

Уровни тестирования:

На всех уровнях тестирования применяются методы:

К методам тестирования относятся также методы проведения испытаний ПО, проверки реализации требований и обеспечения параметров настройки и размещения компонентов ПО на заданном количестве и типах компьютеров, среды и ОС.

Техники тестирования базируются на некоторых теоретических и практических положениях, например, на природе подхода к проектированию (компонентного, объектно-ориентированного, сервисного и т.п.), а также на следующих данных:

Метрики тестирования.Для измерения результатов тестирования ПО, а также при проведении анализа качества используются метрики. Измерение как часть планирования и разработки тестов базируется на размере программ, их структуре и количестве обнаруженных ошибок и дефектов. Метрики тестирования обеспечивают измерение процесса планирования, проектирования и тестирования; а также результатов тестирования на основе таксономии отказов и дефектов, покрытия границ тестирования, проверки потоков данных и др. Процесс тестирования документируется и согласно стандарту IEEE 829-98 включает описание тестовых документов, их связи между собой и с задачами тестирования. Без документации по процессу тестирования невозможно провести сертификацию продукта по модели СММ [1.20]. После завершения тестирования рассматриваются вопросы стоимости и оценки рисков, вызванных сбоями или недостаточно надежной работой системы. Стоимость тестирования является одним из ограничений, на основе которого принимается решение о прекращении или его продолжении.

Управление тестированием:

Заметим, что стандарт ISO/IEC 12207 и гармонизированный ГОСТ 12207 не выделяет деятельность по тестированию в качестве самостоятельного процесса, а рассматривает тестирование как неотъемлемую часть всего ЖЦ.

1.1.5. Сопровождение ПО (Software maintenance)

Сопровождение ПО - совокупность действий по обеспечению работы ПО, а также по внесению изменений в случае обнаружения ошибок в процессе эксплуатации, по адаптации ПО к новой среде функционирования, а также по повышению производительности или улучшению других характеристик ПО. В связи с решением проблемы 2000 года сопровождение стало рассматриваться как более важный процесс, который должны осуществлять разработчики. Новая версия системы должна решать те же самые задачи, иметь план переноса информации в другие обновленные БД и учета стоимости сопровождения. Сопровождение (в соответствии со стандартами ISO/IEC 12207 и ISO/IEC 14764) считается модификацией программного продукта в процессе эксплуатации при условии сохранения целостности продукта.

Область знаний "Сопровождение ПО (Software maintenance)" состоит из следующих разделов:

Сопровождение рассматривается с точки зрения удовлетворения требований к созданному ПО, корректности его выполнения, процессов обучения и оперативного учета процесса сопровождения.

Основные концепции описывают базовые определения и терминологию, подходы к эволюции и сопровождению ПО, а также к оценке стоимости сопровождения и др.

К основным концепциям можно отнести ЖЦ ПО (стандарт ISO/IEC 12207) и составление документации. Главное назначение этой области знаний состоит в выполнении готовой программной системы, фиксации возникающих ошибок при выполнении, исследовании причин ошибок, анализа необходимости модификации системы в целях устранения ошибок, оценки стоимости работ по проведению изменений функций и системы в целом. Рассматриваются проблемы, связанные с увеличением сложности продукта при большом количестве изменений и методы ее преодоления.

Процесс сопровождения включает: модели процесса сопровождения и планирование деятельности людей, которые проводят запуск ПО, проверку правильности его выполнения и внесения в него изменений. Процесс сопровождения согласно стандарту ISO/IEC 14764 проводится путем:

Ключевые вопросы сопровождения ПО.Основными из этих вопросов являются управленческие, измерительные и стоимостные. Сущность управленческих вопросов состоит в контроле ПО в процессе модификации, совершенствовании функций и недопущении снижения производительности системы. Вопросы измерения связаны с оценкой характеристик системы после ее модификации, а также повторного тестирования и оценки показателей качества. Стоимостные вопросы связаны с оценкой затрат на сопровождение ПО в зависимости от его типа, квалификации персонала, платформы и др. Знание этих факторов часто позволяет уменьшить затраты.

Эволюция ПО.Известный специалист в области ПО Дж. Леман (1970г.) предложил рассматривать сопровождение как эволюционную разработку программных систем, поскольку сданная в эксплуатацию система не всегда является полностью завершенной, ее надо изменять в течение срока эксплуатации. В результате программная система становится более сложной и плохо управляемой, возникает проблема уменьшения ее сложности. К технологиям эволюции ПО относятся реинженерия, реверсная инженерия и рефакторинг.

Реинженерия - это усовершенствование устаревшего ПО путем его реорганизации или реструктуризации, а также перепрограммированием отдельных элементов или настройки параметров на другую платформу или среду выполнения с сохранением удобства его сопровождения.

Реверсная инженерия состоит в восстановлении спецификации (графов вызовов, потоков данных и др.) по полученному коду системы для наблюдения за ней на более высоком уровне. Восстанавливается идентификация программных компонентов и связей между ними для обеспечения перепрограммирования системы к новой форме.

Чаще всего реверсная инженерия применяется после того, как в код ПО было внесено много изменений и оно стало неуправляемым.

Рефакторинг - это реорганизация кода для улучшения характеристик и показателей качества объектно-ориентированных и компонентных программ без изменения их поведения. Этот процесс реализуется путем постепенного изменения отдельных операций над текстами, интерфейсами, средой программирования и выполнения ПО, а также настройки или внесения изменений в инструментальные средства поддержки ПО. Если сохраняется форма существующей системы при изменении, то рефакторинг - один из вариантов реверсной инженерии.

1.1.6. Управление конфигурацией ПО

Управление конфигурацией (Software Configuration Management - SCM) состоит в идентификации компонентов системы, определении функциональных и физических характеристик аппаратного и программного обеспечения для контроля за внесением изменений и трассированием конфигурации на протяжении ЖЦ. Это управление соответствует одному из вспомогательных процессов ЖЦ (ISO/IEC 12207), выполняется техническим и административным руководством проекта; составляются отчеты об изменениях, внесенных в конфигурацию, и степени их реализации, а также проводится проверка соответствия внесенных изменений заданным требованиям.

Конфигурация системы - состав функций, программного и технического обеспечения системы, возможные их комбинации в зависимости от наличия оборудования, общесистемных средств, обозначенных в технической документации системы, и требования к продукту.

Конфигурация ПО включает набор функциональных и технических характеристик ПО, заданных в технической документации и реализованных в готовом продукте. Это сочетание разных элементов продукта вместе с заданными процедурами сборки и настройки на среду в соответствии с назначением системы. Примерами элементов конфигурации являются график разработки, проектная документация, исходный и исполняемый код, библиотека компонентов, инструкции по установке и развертыванию системы.

Область знаний "Управление конфигурацией ПО" состоит из следующих разделов:

Управление процессом конфигурации.Это деятельность по контролю эволюции и целостности продукта при идентификации, контроле изменений и обеспечении отчетной информацией, касающейся конфигурации. Включает:

Идентификация конфигурации ПО заключается в документировании функциональных и физических характеристик элементов конфигурации ПО, а также в оформлении технической документация на элементы конфигурации ПО.

Контроль конфигурации ПО состоит в проведении работ по координации, утверждению или отбрасыванию реализованных изменений в элементах конфигурации после формальной ее идентификации, а также в анализе входящих компонентов в конфигурацию и соответствия их идентификации.

Учет статуса или состояния конфигурации ПО проводится с помощью комплекса мероприятий, позволяющих определить степень изменения конфигурации, полученной от разработчика, а также правильность внесенных изменений в конфигурацию ПО при ее сопровождении. Информация и количественные показатели накапливаются в соответствующей БД и используются при управлении конфигурацией, составлении отчетности, оценивании качества и выполнении других процессов ЖЦ.

Аудит конфигурации - это деятельность, которая выполняется для оценки продукта и процессов на соответствие стандартам, инструкциям, планам и процедурам. Аудит определяет степень, в которой элемент конфигурации удовлетворяет заданным функциональным и физическим (аппаратным) характеристикам системы. На основе функционального и физического аудита конфигурации фиксируется базовая линия изготовленного продукта.

Управление версиями ПО - это отслеживание имеющейся версии элемента конфигурации; сборка компонентов; создание новых версий системы на основе существующих путем внесения изменений в конфигурацию; согласование версии продукта с требованиями и проведенными изменениями на этапах ЖЦ; обеспечение оперативного доступа к информации об элементах конфигурации и системы, к которым они относятся. Управление выпуском охватывает идентификацию, упаковку и передачу элементов продукта и документации заказчику. При этом используются следующие основные понятия.

Базис (baseline) - формально обозначенный набор элементов ПО, зафиксированный на этапах ЖЦ ПО.

Библиотека ПО - контролируемая коллекция объектов ПО и документации, предназначенная для облегчения процесса разработки, использования и сопровождения ПО.

Сборка ПО - объединение корректных элементов ПО и конфигурационных данных в единую исполняемую программу.

1.1.7. Управление инженерией ПО

Управление инженерией ПО (Software Engineering Management) - руководство работами команды разработчиков ПО в процессе выполнения плана проекта, определение критериев эффективности работы команды и оценка процессов и продуктов проекта с использованием общих методов управления, планирования и контроля работ.

Как любое управление, менеджмент ПО базируется на планировании, координации, измерении, контроле и учете процесса управления проектом. Координацию людских, финансовых и технических ресурсов при реализации задач программного проекта выполняет менеджер проекта, аналогично тому, как это делается в технических проектах. В его обязанности входит соблюдение запланированных бюджетных и временных характеристик и ограничений, стандартов и сформулированных требований. Общие вопросы управления проектом содержатся в ядре знаний РMBOK [1.21] в разделе Management Process Activities, а также в стандарте ISO/IEC 12207 - Software life cycle processes [1.14], где управление проектом рассматривается как дополнительный и организационный процесс ЖЦ.

Область знаний "Управление инженерией ПО (Software Engineering Management)" состоит из следующих разделов:

Организационное управление - это планирование и составление графика работ, оценка стоимости работ, подбор и управление персоналом, контроль за выполнением работ согласно принятым стандартам и планам. Главными проблемами организационного управления проектом являются: управление персоналом (обучение, мотивация и др.), коммуникации между сотрудниками (сценарии, встречи, презентации и др.), а также риски (минимизация риска, техники определения риска и др.). Для управления проектом создается определенная структура коллектива, специалисты распределяются по работам и решают задачи проекта под руководством менеджера с учетом заданной стоимости и сроков разработки. Для задач проекта подбираются также необходимые программные, инструментальные и аппаратные средства.

Управление проектом/процессом включает: составление плана проекта, построение графиков работ (сетевых или временных диаграмм) с учетом имеющихся ресурсов, распределение персонала по работам проекта, исходя из заданных сроков и стоимости их выполнения. Для эффективного управления проектом проводится анализ финансовой, технической, операционной и социальной политики организации разработчика для выбора правильной стратегии выполнения плана, контроля процесса управления планами и выпуском промежуточных продуктов (проектных решений, диаграмм UML, алгоритмов и др.).

В задачи управления проектом входят также уточнение требований, проверка их на соответствие заданным спецификациям характеристик качества, а также верификация функций отдельных продуктов проекта. Процесс управления проектом базируется на плановых сроках выполнения работ. Результаты планирования отображаются в сетевых диаграммах PERT (Program Evaluation and Review Technique), CРM (Сritical Path Method) и др., предназначенных для отображения всех аспектов работ, в частности, времени их выполнения и связей между разными работами в проекте.

На сегодняшний день наиболее распространенным представлением сети для управления разными видами работ является сетевая диаграмма PERT - граф, в вершинах которого располагаются работы, а дуги задают взаимные связи между этими работами. Другой тип сетевой диаграммы, CPМ, является событийным. В вершинах такой диаграммы указываются события, а работы задаются линиями между двумя узлами событиями. Ожидаемое время выполнения работы для сетевых диаграмм оценивается с помощью среднего весового значения трех оценок: оптимистической, пессимистической и ожидаемой, т.е. вероятностной. Эти оценки берутся из заданного времени на разработку и заключений экспертов, оценивающих как отдельные работы, так и весь комплекс работ. Есть и другие методы оценок.

После составления плана решается вопрос управления проектом и контроля работ в соответствии с планом, выбранным процессом и сущностью проекта. Корректно составленный план обеспечивает выполнение требований и целей проекта. Контроль осуществляется при внесении изменений в проект, направлен на оценку риска и принимаемых решений по минимизации рисков.

Важной проблемой выполнения проекта является процесс определения рисков и разработки мероприятий по уменьшению их влияния на ход выполнения проекта. Под риском понимается вероятность проявления неблагоприятных обстоятельств, которые могут повлиять негативно на управление разработкой (например, увольнение сотрудника и отсутствие замены для продолжения работ и др.). При составлении плана проекта проводится идентификация и анализ риска, планирование непредвиденных ситуаций, касающихся рисков. Предотвращение риска заключается в выполнении действий, которые снимают риск (например, увеличение времени разработки и др.), что уменьшает вероятность появления нового риска при реорганизации проекта, БД или транзакций, а также при выполнении ПО.

Инженерия измерений ПО проводится в целях определения отдельных характеристик продуктов и процессов, инженерии планирования и измерения этих характеристик (например, количество строк в продукте, ошибок в спецификациях и т.п.). Предварительно проводятся работы по выбору метрик процессов и продуктов с учетом обстоятельств и зависимостей, влияющих на измерение их характеристик. К аспектам инженерии измерений относятся совершенствование процессов управления проектом; оценки временных затрат и стоимости ПО, их регулирование; определение категорий рисков и отслеживание факторов для регулярного расчета вероятностей их возникновения; проверка заданных в требованиях показателей качества отдельных продуктов и проекта в целом [1.15].

Проведение разного рода измерений является важным принципом любой инженерной деятельности. В программном проекте результаты измерений необходимы заказчику и потребителям, чтобы установить, действительно ли проект был реализован правильно. Без измерений в инженерии ПО процесс управления становится неэффективным и превращается в самоцель.

1.1.8. Процесс инженерии ПО (Software Engineering Process)

В некотором смысле это метауровень, который связан с определением, реализацией, оценкой, измерением, управлением изменениями и совершенствованием самого процесса. Однако такой процесс не является единственно правильным способом выполнения задач программной инженерии. На самом деле стандарты о процессах (ГОСТ 12207) говорят о том, что процессов много, например основной процесс разработки (Development Process), процесс управления конфигурацией (Configuration Management Process) и т.п.

Для оценивания и совершенствования процессов программной инженерии используется модель зрелости (Capability Maturity Models - CMM), эту концепцию разработал институт программной инженерии SEI (Software Engineering Institute) США. Модель описывает существенные атрибуты, которыми должен обладать процесс, находящийся на определенном уровне зрелости, а также указывает практические приемы обеспечения уровня абстракции без ограничений на способы реализации процесса в конкретном проекте. Разновидностями этой модели являются: СMM - SW (software) для оценки ПО, CMMI - вариант СММ для учета потребностей крупных государственных структур США, Bootstrap - вариант СММ для малых и средних коммерческих компаний, ISO - 15504 (Software Process Improvement and Capability - SPICE), ISO 9000-3 как приложение к общей модели качества ISO 9001 и др.

Концепция зрелости процесса ПО основывается на интеграции концепции процесса ПО (software process), широты возможностей процесса ПО (software process capability), результативности процесса ПО (software process performance) и зрелости процесса ПО (software process maturity). Процесс ПО в модели СММ - это множество деятельностей (activities), методов (methods), практических приемов и процедур (practices), используемых при разработке ПО и связанных с ним продуктов (например, планов проекта, проектных документов, кода, тестов, руководства пользователя и др.).

Зрелость процесса - это степень его четкости определения, управления, измерения, контроля.

СММ предоставляет шаблон для улучшения процесса в виде пяти уровней зрелости, которые создают основу непрерывного улучшения процесса. Эти пять уровней зрелости определяют шкалу упорядочения для измерения зрелости процесса ПО организации и оценивании возможностей этого процесса. Уровень зрелости - это определенные средства для достижения зрелого процесса, а именно, множество целей процесса, которые, в случае их достижения, стабилизируют процесс в проектной организации.

Область знаний "Процесс программной инженерии (Software Engineering Process)" состоит из следующих разделов:

Концепции процесса инженерии ПО - задачи и действия, которые связаны с управлением, реализацией, оценкой, изменениями и совершенствованием процесса и/или ПО. Цель управления процессом - это создание инфраструктуры процесса, выделение необходимых ресурсов, планирование реализации и изменения процесса в целях внедрения его в практику и, наконец, оценка преимущества от его внедрения при реальной практике проектирования конкретного проекта.

Инфраструктура проекта - это его ресурсы (человеческие, технические, информационные и программные), стандарты, службы управления качеством и риском, а также форма организации производства проектов: бригада, экспериментальная фабрика (Experimental Factory), линейка программных продуктов (Framework for Product Line Practice) и др. Она также включает управление и коммуникации в коллективе, инженерные методы организации и производства программного продукта. Главная задача инфраструктуры - совершенствование процесса с учетом опыта разработки ПО.

Определение процесса основывается на: типах процессов и моделей (водопадная, спиральная, итерационная и др.); моделях ЖЦ процессов и средств, стандартах ЖЦ ПО ISO/IEC 12207 и 15504, IEEE std. 1074-91 и 1219-92; а также методах и нотациях задания процессов и автоматизированных средствах их поддержки. Основной целью процесса является повышение качества получаемого продукта, улучшение различных аспектов программной инженерии, автоматизация процессов и др.

Оценка процесса проводится с использованием соответствующих моделей и методов оценки. Например, оценка потенциальной способности специалиста к выполнению соответствующей работы. SWEBOK обращает внимание на процедуру оценки потенциальной возможности заключения контракта на разработку, организации разработки ПС на основе модели оценки зрелости (СММ) и процессов, согласно которым проводится разработка ПО.

Оценки относятся также и к техническим работам в сфере программной инженерии, к управлению персоналом и качеству ПО. Для этого проводятся экспериментальные исследования среды, наблюдение за выполнением процесса, сбор информации, моделирование, классификация полученных ошибок и дефектов, а также статический анализ недостатков процесса в сравнении с существующими стандартами (например, ГОСТ 12207) и потенциальных аспектов совершенствования процесса.

Качественный анализ процесса состоит в идентификации и поиске слабых мест в процессе создания ПО до начала его функционирования. Рассматривается две техники анализа: обзор данных и сравнение процесса с основными положениями стандарта ISO/IEC 12207; сбор данных о качестве процессов; анализ главных причин отказов в функционировании ПО, откат назад от точки возникновения отклонения до точки нормальной работы ПО для выяснения причин изменения процесса. На качество результатов проекта и процесса влияют применяемые инструменты и опыт специалистов.

Выполнение и изменение процесса. Существует ряд фундаментальных аспектов измерений в программной инженерии, лежащих в основе детальных измерений процесса. Оценка совершенствования процессов проводится для установления количественных характеристик процесса и продуктов. После процесса развертывания ПО, выполняются вычисления функций и инспекция результатов выполнения. Результаты процесса могут касаться оценки качества продукта, продуктивности, трудозатрат и др. Если результаты не удовлетворяют пользователя ПО, то проводится анализ и принятие решений о необходимости изменения или усовершенствования процесса, организационной структуры проекта и некоторых инструментов управления измерениями.

1.1.9. Методы и инструменты инженерии ПО

Методы обеспечивают проектирование, реализацию и выполнение ПО. Они накладывают некоторые ограничения на инженерию ПО в связи с особенностями применения их нотаций и процедур, а также обеспечивают оценку и проверку процессов и продуктов. Инструменты являются программной поддержкой отдельных методов инженерии ПО и обеспечивают автоматизированное выполнение задач процессов ЖЦ.

Область знаний "Методы и инструменты инженерии ПО (Software Engineering Tools and Methods)" состоит из разделов:

Методы инженерии ПО - это эвристические методы (heuristic methods), формальные методы (formal methods) и методы прототипирования (prototyping methods),.

Эвристические методы включают: структурные методы, основанные на функциональной парадигме; методы, ориентированные на структуры данных, которыми манипулирует ПО; объектно-ориентированные методы, которые рассматривают предметную область как коллекцию объектов, а не функций; методы, ориентированные на конкретную область применения, например, на системы реального времени, безопасности и др.

Формальные методы основаны на формальных спецификациях, анализе, доказательстве и верификации программ. Формальная спецификация записывается на языке, синтаксис и семантика которого определены формально и основаны на математических концепциях (алгебре, теории множеств, логике). Различаются следующие категории формальных методов:

Эти методы применялись в основном в теоретических экспериментах и более 25 лет их практическое применение было ограничено из-за трудоемкости и экономической невыгодности. В 2005 г. проблема верификации приобрела вновь актуальность в связи c разработкой нового международного проекта по верификационному ПО "Целостный автоматизированный набор инструментов для проверки корректности ПС" (идея Т. Хоара, "Открытые системы", 2006, № 6), ставящим следующие перспективные задачи:

Предполагается, что формальные методы верификации будут охватывать все аспекты создания и проверки правильности программ. Это приведет к созданию мощной верификационной производственной основы и значительному сокращению ошибок в ПО (доказательству и верификации будет посвящена тема 7.)

Методы прототипирования (Prototyping Methods) основаны на прототипировании ПО и подразделяются на:

Инструменты инженерии ПО обеспечивают автоматизированную поддержку процессов разработки ПО и включают множество разных инструментов, охватывающих все процессы ЖЦ.

Инструменты работы с требованиями (Software Requirements Tools) - это:

Инструменты проектирования (Software Design Tools) - это инструменты для создания ПО с применением базовых нотаций (SADT/IDEF, UML, Microsoft DSL, Oracle и т.п.).

Инструменты конструирования ПО (Software Construction Tools) - это инструменты для производства, трансляции программ и машинного выполнения. К ним относятся:

Инструменты тестирования (Software Testing Tools) это:

Инструменты сопровождения (Software Maintenance Tools) включают в себя:

Инструменты конфигурационного управления (Software Configuration Management Tools) - это:

Инструменты управления инженерной деятельностью (Software Engineering Management Tools) состоят из:

Инструменты поддержки процессов (Software Engineering Process Tools) разделены на:

Инструменты обеспечения качества (Software Quality Tools) делятся на две категории:

Дополнительные аспекты инструментального обеспечения (Miscellaneous Tool Issues) соответствуют таким аспектам:

1.1.10. Качество ПО (Software Quality)

Качество ПО - набор свойств продукта (сервис или службы), которые характеризуют его способность удовлетворить установленные или предполагаемые потребности заказчика. Понятие качества имеет разные интерпретации в зависимости от конкретной системы

и требований к программному продукту. Кроме того, в разных источниках таксономия (классификация) характеристик в модели качества отличается.

Каждая модель имеет различное число уровней, и все известные модели качества имеют полное или частичное совпадение набора характеристик качества. Например, модель качества МакКолла на самом высоком уровне имеет три характеристики: функциональность, модифицируемость и переносимость, а на более нижних уровнях модели, 11 подхарактеристик качества и 18 критериев (атрибутов) качества.

Стандарт ISO 9126-01 рассматривает внешние и внутренние характеристики качества. Первые отображают требования к функционирующему программному продукту. Для количественного задания критериев качества, по которым будет осуществляться проверка и подтверждение соответствия ПО заданным требованиям, определяются соответствующие внешние измеряемые свойства (внешние атрибуты ) ПО и метрики. Ими могут быть конкретные значения (например, время выполнения отдельных компонентов), диапазоны изменения значений для некоторых внешних атрибутов и модели их оценивания. Метрики, применение которых возможно только для ПО, функционирующего на компьютере, используются на стадии тестирования или функционирования. Они называются внешними метриками и представляют собой модели оценивания атрибутов.

Внутренние характеристики качества и внутренние атрибуты ПО используются при составлении плана достижения необходимых внешних характеристик качества для конечного программного продукта. Для квантификации внутренних характеристик качества специфицируются внутренние метрики, использующиеся при проверке соответствия промежуточных продуктов спецификациям внутренних требований к качеству, которые формулируются на этапах, предшествующих тестированию (определение требований, проектирование, кодирование).

Внешние и внутренние характеристики качества отображают свойства самого ПО (работающего или не работающего), а также взгляд заказчика и разработчика на это ПО. Непосредственного конечного пользователя ПО интересует эксплуатационное качество ПО - совокупный эффект от достижения характеристик качества, который измеряется в сроках использования результата, а не свойств самого ПО. Это понятие шире, чем любая отдельная характеристика (например, удобство использования или надежность).

Окончательная оценка качества проводится в соответствии со стандартом ISO 15504-98 [1.15]. Качество может повышаться за счет постоянного улучшения используемого продукта в связи с процессами обнаружения, устранения и предотвращения сбоев/дефектов в ПО.

Область знаний "Качество ПО (Software Quality)" состоит из следующих разделов:

Концепция качества ПО - это внешние и внутренние характеристики качества, их метрики, а также модели качества, определенные на множестве этих характеристик, которые представлены в стандартах качества [1.16] - это шесть характеристик и каждая из них имеет несколько атрибутов. К характеристикам качества относятся:

Базовая модель качества включает эти характеристики и относится к любому типу программных продуктов. При разработке требований заказчик формулирует те требования к качеству, которые наиболее подходят для заказываемого программного продукта.

Определение и планирование качества ПО основывается на положениях стандартов в этой области, составлении планов и графиков работ, процедурах проверки и др. План обеспечения качества включает набор действий для проверки процессов обеспечения качества (верификация, валидация и др.) и формирование документа по управлению качеством.

Планирование качества обеспечивает управление процессами обеспечения качества продуктов проекта (в частности промежуточных рабочих продуктов) и ресурсов - программных, технических,

исполнительских и др., а также включает управление требованиями к процессам и продуктам. Планирование качества включает:

В стандарте 12207 определены специальные процессы: обеспечения качества, верификации, аттестации (валидации), совместного анализа и аудита.

Деятельности и техники гарантии качества включают: инспекцию, верификацию и валидацию ПО.

Инспекция ПО - анализ и проверка различных представлений системы и ПО (спецификаций, архитектурных схем, диаграмм, исходного кода и др.). Выполняется на всех этапах ЖЦ разработки ПО.

Верификация ПО - процесс обеспечения правильной реализации ПО, которое соответствует спецификациям, выполняется на протяжении всего жизненного цикла. Верификация дает ответ на вопрос, правильно ли создана система.

Валидация - процесс проверки соответствия ПО функциональным и нефункциональным требованиям и ожидаемым потребностям заказчика.

Верификация и валидация начинают выполняться на ранних стадиях ЖЦ и ориентированы на качество. Они планируются и обеспечиваются определенными ресурсами с четким распределением ролей. Проверка основывается на использовании соответствующих техник тестирования для обнаружения тех или иных дефектов и сбора статистики. В результате собранных данных проводится оценка правильности реализации требований и работы ПО в заданных условиях.

Измерение в анализе качества ПО основывается на метриках продукта и данных, собранных в процессе создания продукта при заданных ресурсах, на оценках процессов, ПО и его моделях, а также на документировании измерений. Оценка качества продукта - это измерение и оценивание качественных показателей с помощью данных о разных типах ошибок и отказах во время тестирования ПО и исполнения кода на тестовых данных. Эти данные анализируются,

проверяются и используются при качественной и количественной оценке ПО.

Для имитации работы системы в режиме тестирования разрабатываются тесты с реальными входными данными для проверки правильности работы ПО на разных фрагментах программы и путях следования в них операторов. В процессе тестирования ПО обнаруживаются разного рода ошибки (отказы, дефекты, ошибки и т.п.), количество которых в значительной степени может повлиять на получение правильного результата.

С учетом типов обнаруженных ошибок можно установить наличие (или отсутствие) соответствия реализованных и нереализованных функций, заданных в требованиях к системе, а также оценить принципы реализации нефункциональных требований (производительность, надежность и др.). Проводятся также оценки процессов управления планами, инспекциями, прогонами и т.п. По этим оценкам принимаются решения о завершении разработки продукта проекта и передаче его заказчику в опытную эксплуатацию или о необходимости внесения изменений для устранения ошибок, определения адекватности планов и требований, оценки рисков на переделку ПО и др.

Целью инспекций является обнаружение различных аномальных состояний в ПО независимыми специалистами команды экспертов и с привлечением авторов промежуточного или конечного продукта. Эксперты инспектирует выполнение требований, интерфейсы, входные данные и т.п., а затем документируют обнаруженные отклонения в проекте.

Назначением аудита является независимая оценка продуктов и процессов на соответствие регулирующим и регламентирующим документам (планам, стандартам и др.), формулирование отчета о случаях несоответствия и предложений для их корректировки.

1.2. Жизненный цикл ПС, связь с ядром знаний SWEBOK

Программная инженерия, как инженерная дисциплина, охватывает все аспекты создания ПС от начальной стадии разработки системных требований до реализации программного продукта и его использования.

Под программной системой (ПС) понимается комплекс интегрированных программ и средств, которые реализуют функции предметной области в заданной среде. В комплекс могут входить: прикладные системы (зарплата, учет и др.), общесистемные компоненты (отладчик, редактор, СУБД), системы защиты и безопасности и др.

Программное обеспечение - это некоторая конкретная функции системы (например, программный модуль решения одной общей задачи, ОС - функционирование программ и систем, управление данными и др.). ПО может входить в состав ПС или быть идентичным ПС.

Каждая ПС на протяжении своего существования проходит определенную последовательность процессов (этапов), начиная от постановки задачи до ее воплощения в готовую программу, эксплуатации и изъятия из эксплуатации. Такая последовательность этапов называется жизненным циклом (ЖЦ) разработки ПС. На каждом этапе ЖЦ выполняется определенная совокупность процессов и/или подпроцессов, каждый из которых порождает соответствующий промежуточный продукт, используя при этом результаты предыдущего процесса и продукта.

Все продукты программной инженерии представляют собой некоторые описания, а именно, тексты требований к разработке ПС, согласованные договоренности с заказчиком, архитектуру, структуру данных, тексты программ, документацию, инструкции по эксплуатации и т.п. Главные ресурсы разработки ПС в программной инженерии - это сроки, время и стоимость. Правильное управление и использование этих ресурсов при выполнении задач и действий процессов ЖЦ определяет эффективность разработки ПС.

Разновидности действий и задач, представленные в процессах ЖЦ ПС, отображены в международном стандарте ISO\IEC 12207 (таблица 1) и связаны содержательно с областями знаний SWEBOK.

Данный стандарт устанавливает общую структуру и содержание ЖЦ ПС, начиная от разработки концепции до утилизации системы. Структура представляет собой множество процессов, взаимосвязей между ними и определений действий и задач на процессах ЖЦ. Иными словами, ЖЦ определяет, что надо делать, а не как выполнять те или иные действия.

Стандарт не обязывает использовать определенную модель ЖЦ ПО или конкретную методологию разработки ПО и не предъявляет требования к формату и содержанию создаваемых документов. Поэтому организация-пользователь этого стандарта должна для своей работы разработать стандарты предприятия, методики и процедуры, определяющие разные детали процесса разработки ПО.

Отметим, что ISO выпустил ряд руководств и процедур, дополняющих стандарт ISO\IEC 12207. Основная идея данного стандарта - разработка и сопровождение ПС я так, как этого требует инженерная дисциплина. В процессе разработки создается каркас системы (абстрактная архитектура с вы деленными объектами), для которой определены среда, виды обеспечения, исполнители и сроки.

Как видно из табл. 1.1, все процессы в данном стандарте разделены на три категории:

Для каждого из процессов определены виды деятельности (действия - activity), задачи, совокупность результатов (выходов) видов деятельности и задач, а также некоторые специфические требования. Стандарт дает перечень работ для основных обеспечивающих и организационных процессов. Пункты 1.1.1, 1.1.2, а также категории 2 и 3 процессов определяют виды деятельности, цели и задачи которых оговорены в стандарте, но не определяют форму их представления.

К основным процессам относятся:

К обеспечивающим процессам создания ПС относятся: документирование, управление версиями, верификация и валидация, просмотры, аудиты, оценивание продукта и др. Процессы управления версиями соответствуют управлению конфигурацией системы, которая так же, как и продукты процессов должна проверяться на правильность реализации целей проекта и соответствия требованиям заказчика. Задачи проверки рекомендуется выполнять специальным контролерам, обладающим знаниями методов и процессов проектирования ПС.

К организационным процессам отнесены: управление проектом (менеджмент разработки), качеством и рисками и др. Эти процессы выполняются специальными службами, выполняющими планирование работ на проекте, контроль процессов, определение метрик для измерения продуктов, проверку показателей качества, соблюдение стандартных положений и др.

Процессы, определенные в стандарте ISO/IEC 12207, охватывают все возможные задачи и действия по проектированию и разработке ПС. Пользователь стандарта может выбрать из них соответствующее подмножество для достижения конкретной цели, стоящей перед данным проектом. Процессы, действия и задачи приведены в стандарте в наиболее общей естественной последовательности. В зависимости от целей конкретного проекта процессы, действия и задачи выбираются, упорядочиваются и применяются итерационно или рекурсивно. Главный разработчик и менеджер должны определить задачи проекта, выбрать под их реализацию модель ЖЦ ПО, которая позволит учитывать ресурсы, стоимость и временные характеристики программного проекта.

Данный стандарт определяет содержание деятельности в сфере технологии разработки ПС, а знания, которые необходимы исполнителям для выполнения всех видов деятельности по проектированию и реализации поставленных задач перед проектом, определяют методы и средства областей ядра знаний SWEBOK, которые распределяются по отдельным процессам и подпроцессам при формировании модели ЖЦ для конкретного проекта.

Как уже отмечалось, между стандартом ISO\IEC 12207 и ядром знаний SWEBOK существует связь и взаимовлияние друг на друга, тем более что в разработке обоих документов примерно в одно время принимали участие высококвалифицированные специалисты в области программирования и информатики.

Общие идеи и методы программирования, сложившиеся в 90-х годах прошлого столетия, проникли в оба направления и оказали влияние на их структуру и содержание. Программисты-профессионалы систематизировали накопившиеся знания и создали 10 разделов, которые близки процессам ЖЦ по целям, задачам и видам деятельности. В ядре знаний SWEBOK они изложены как фундаментальные знания и инженерные методы управления разработкой ПО, а в стандарте как общие положения, структура и регламентированные процессы проектирования как рекомендации по разработке проекта, начиная от процесса постановки требований до эксплуатации ПО.

Следует отметить, что структура ядра знаний SWEBOK не лишена недостатков. Так, между областями знаний в этом ядре имеются пересечения, а некоторые важные направления в области программирования вообще не отражены в нем. Например, методы доказательства правильности программ, эволюция программ, распределенные и неоднородные среды, взаимодействие систем, некоторые методы программирования (сервисные, аспектные, агентные и др.), CASE-системы и др.

Технологические процессы в стандарте структурированы системно. Они не устанавливают связь с существующими методами и средствами программной инженерии, что создает возможность выбирать подходящие процессы стандарта и сопоставлять им привычные методы (объектные, компонентные, сервисные и др.), т.е. те, которые уже использовались коллективом разработчиков и для которых есть инструменты поддержки. Это и отражает идею совершенствования процесса инженерии ПО.

Процессы стандарта отвечают на вопрос, какие действия и задачи процессов ЖЦ надо выбрать, чтобы построить конкретную ПС. Ядро знаний SWEBOK отвечает на вопрос, какими методами, средствами и инструментами надо выполнять регламентированные действия и задачи процессов ЖЦ, чтобы построить ПС.

Программная инженерия сформировалась как инженерная дисциплина, которая базируются на теоретических и прикладных методах и средствах разработки ПС и стандартах (ISO/IEC 12207, 15404, ISO 9126 и др.), содержащих рекомендации, правила и методики управления разработкой ПС. Эти два базиса объединяет инженерия оценивания результатов на процессах ЖЦ, управление качеством ПС, оценка затраченных ресурсов на создание и учет стоимости работ участников разработки.

Инженерия программирования делает акцент на принципы, методы и подходы к управлению проектом, конфигурацией и качеством ПС. Стандарты регламентируют основные процессы, определяющие порядок проведения работ по реализации ПС, рекомендуют процессы организационной деятельности по управлению, планированию и оцениванию работ, выполняемых при проектировании и разработке ПС.

Ядро знаний SWEBOK, а также многочисленные монографии и статьи по методам и средствам программной инженерии предоставляют всю необходимую информацию для выбора наиболее подходящего метода, средства, инструмента. Вместе с тем стандарт - это руководство к построению процессов в сочетании с методами для реализации конкретного программного проекта на стандартизованной инженерной основе.

Естественно, что в небольших программных проектах всегда будет место творческим и неформальным подходам, вносимым отдельными профессионалами, при создании разного рода уникальных продуктов, процесс разработки которых не всегда вкладывается в общее стандартное русло.

Таким образом, программная инженерия базируется на ядре SWEBOK и стандартах ЖЦ. Инженерия производства ПС основывается на стандартных организационных процессах - планирования, управления и сопровождения. Цель планирования - составление планов и графиков работ по реализации проекта и распределение работ между разными категориями специалистов с учетом их квалификации и уровня знаний проблематики программной инженерии. Второй процесс обеспечивает привнесение методов управления в процесс выполнения работ по программированию, а именно, управление временем, стоимостью и сроками. Третий процесс - это выполнения проекта, обнаружение и устранение найденных недостатков и замена или внесения новых функций в систему.

Контрольные вопросы и задания