Глава 1. Жизненный цикл программного обеспечения
1.1. Требования к ПО (Software Requirements)
Методологическую основу проектирования ПО составляет системный подход. Под словом «система» понимается совокупность взаимодействующих компонентов и взаимосвязей между ними. Весь мир можно рассматривать как сложную взаимосвязанную совокупность естественных и искусственных систем.
Системный подход – это методология исследования объектов любой природы как систем, которая ориентирована на:
• раскрытие целостности объекта и обеспечивающих его механизмов;
• выявление многообразных типов связей объекта;
• сведение этих связей в единую картину.
Программное обеспечение, в свою очередь, определяется как набор компьютерных программ, процедур и, возможно, связанной
с ними документации и данных.
По определению Института управления проектами (Project Management Institute, PMI), проект – это временное предприятие, осуществляемое с целью создания уникального продукта или услуги. В любой инженерной дисциплине под проектированием обычно
понимается некий унифицированный подход, с помощью которого мы ищем пути решения определенной проблемы, обеспечивая выполнение поставленной задачи. В контексте инженерного проектирования можно определить цель проектирования как создание системы, которая:
удовлетворяет заданным (возможно, неформальным) функциональным спецификациям;
согласована с ограничениями, накладываемыми оборудованием;
удовлетворяет явным и неявным требованиям по эксплуатационным качествам и потреблению ресурсов;
удовлетворяет явным и неявным критериям дизайна продукта;
удовлетворяет требованиям к самому процессу разработки, таким, например, как продолжительность и стоимость, а также привлечение дополнительных инструментальных средств.
В другой формулировке цель проектирования – выявление ясной и относительно простой внутренней структуры, называемой архитектурой системы. Проект есть окончательный продукт процесса проектирования. Проектирование подразумевает учет противоречивых требований. Его продуктами являются модели, позволяющие понять структуру будущей системы, сбалансировать требования и наметить схему реализации.
Таким образом, под проектом ПО будем понимать совокупность спецификаций ПО (включающих модели и проектную документацию), обеспечивающих создание ПО в конкретной программно-технической среде.
Проектирование ПО представляет собой процесс создания спецификаций ПО на основе исходных требований к нему. Проектирование ПО сводится к последовательному уточнению его спецификаций на различных стадиях процесса создания ПО.
Международным комитетом при американском объединении компьютерных специалистов ACM (Association for Computing Mac-hinery) и институте инженеров по электронике и электротехнике IEEE Computer Society было создано ядро знаний SWEBOK
(рис. 1.1, 1.2). В этом ядре были систематизированы разнородные знания в области программирования, планирования и управления, сформулировано понятие программной инженерии и десяти областей, которые соответствуют процессам проектирования ПО и методам их поддержки.
Понятие «жизненный цикл ПО» (ЖЦ ПО) является одним из базовых понятий программной инженерии.
ЖЦ ПО – это период времени, который начинается с момента решения о необходимости создания ПО и заканчивается полным изъятием его из эксплуатации.
Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995 «Information Technology – Software Life Cycle Processes». Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО (его российский аналог ГОСТ РИСО/МЭК 1220799 введен в действие в июле 2000 г.). В данном стандарте процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами.
Рис. 1.1. Основные области знаний SWEBOK
Рис. 1.2. Организационные области знаний SWEBOK
Каждый процесс разделен на набор действий, каждое действие – на набор задач. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем не существует заранее определенных последовательностей выполнения (естественно, при сохранении связей по входным данным).
1.2. Процессы ЖЦ стандарта ISO/IEC 12207
При выборе схемы модели ЖЦ для конкретной предметной области, решаются вопросы включения важных для создаваемого продукта видов работ или не включения несущественных работ. На сегодня основой формирования новой модели ЖЦ для конкретной прикладной системы является стандарт ISO/IEC 12207, который задает полный набор процессов (более 40), охватывающий все возможные виды работ и задач, связанных с построением программных средств (ПС), начиная с анализа предметной области и кончая изготовлением соответствующего продукта. Данный стандарт содержит основные (рис. 1.3) и вспомогательные процессы (рис. 1.5).
Рис. 1.3. Процессы ГОСТ РИСО/МЭК 1220799
На рис. 1.4 представлены процессы, связанные непосредственно с разработкой ПС. К категории основных процессов относятся также «первичные» процессы, определяющие порядок подготовки договора на разработку ПС, мониторинг деятельности поставщиков ПС заказчику.
Стандарт ISO/IEC 12207 предоставляет структуру процессов ЖЦ, но не обязывает использовать все процессы в модели ЖЦ ПО или в конкретной методологии разработки ПО. Являясь стандартом высокого уровня, он не задает детали того, как надо выполнять действия или задачи, составляющие процессы. Он также не задает требований к формату и содержанию документов, выпускаемых на разных процессах.
Рис. 1.4. Схема основных процессов ЖЦ ПС
Стандарт ISO/IEC 12207 является основой для принятия других стандартов, связанных с ним. Например, стандартов по управлению ПО, обеспечению качества, верификации и валидации, управлению конфигурацией, метриками ПО и т.д.
Валидация требований – это проверка изложенных в спецификации требований, выполняющаяся для того, чтобы путем отслеживания источников требований убедиться, что они определяют именно данную систему. Заказчик и разработчик ПО проводят экспертизу сформированного варианта требований с тем, чтобы разработчик мог далее проводить проектирование ПО. Один из методов валидации – прототипирование, т.е. быстрая отработка отдельных требований на конкретном инструменте и исследование масштабов изменения требований, измерение объема функциональности и стоимости, а также создание моделей оценки зрелости требований.
Верификация требований – это процесс проверки правильности спецификаций требований на их соответствие, непротиворечивость, полноту и выполнимость, а также на соответствие стандартам. В результате проверки требований делается согласованный выходной документ, устанавливающий полноту и корректность требований к ПО, а также возможность продолжить проектирование ПО.
Из данного стандарта можно выбрать только те процессы, которые более всего подходят для реализации конкретной ПС. Обязательными являются основные процессы, которые присутствуют во всех известных моделях ЖЦ. В зависимости от целей и задач предметной области они могут быть пополнены дополнительными (документирование, обеспечение качества, верификация и валидация и т.п.) и организационными (планирование, управление и др.) процессами этого стандарта.
Процессы, включенные в модель ЖЦ, предназначены для реализации стандартных задач процессов ЖЦ и могут привлекать другие процессы для реализации специализированных задач системы (например, защиты данных). Интерфейсы (входы и выходы) любых двух процессов ЖЦ должны быть минимальными и каждый из них должен удовлетворять следующим правилам:
если процесс А вызывается процессом В и только процессом В, то А принадлежит В;
если функция вызывается более чем одним процессом, то она становится отдельным процессом;
проверка любой функции в ЖЦ является обязательной.
Рис. 1.5. Схема вспомогательных процессов ЖЦ ПС
Если задача требуется более чем одному процессу, то она может стать процессом, используемым однократно или многократно на протяжении жизни конкретной системы. Каждый процесс должен иметь внутреннюю структуру, установленную в соответствии с тем, что он должен выполнять.
Каждый процесс ЖЦ подкрепляется выбранными для реализации задач ПС средствами, методами программирования и методикой их применения и выполнения.
Важную роль при формировании модели ЖЦ имеют организационные аспекты:
планирование последовательности работ и сроков их исполнения;
подбор и подготовка ресурсов (людских, программных и технических) для выполнения работ;
оценка возможностей реализации проекта в заданные сроки, стоимость и ресурсы.
Пример разработки ЖЦ ПС с задачами и действиями
для процесса тестирования.
Основное назначение процесса тестирования ЖЦ – выполнение задач процесса на основе входов (входные данные для выполнения задач процесса) и выходов при завершении задач, а также ролей и действий исполнителей этих задач.
В соответствии со стандартом ISO/IEC 12207 были выявлены задачи тестирования и распределены по процессам ЖЦ ПС. В результате был получен единый непрерывный процесс тестирования разных ПС, задачами которого являются подготовка, проведение и оценивание результатов тестирования, которые распределились по
20 действиям (шагам) процесса разработки. Данный подход к тщательному тестированию ПС целесообразно применять, например, для систем реального времени.
На шаге подготовки осуществляется анализ рабочих продуктов процесса разработки ПС (входных для данного шагу процесса тестирования) для определения целей, объектов, сценариев и ресурсов тестирования, адекватных шагу тестирования. Результаты выполнения шагов подготовки тестирования должны фиксироваться в планах тестирования.
На шаге выполнения осуществляется фиксация результатов выполнения тестов, их сравнение с ожидаемыми результатами, определение текущего состояния рабочего продукта ПС и принятие решения о достаточности тестирования.
Каждый шаг процесса разработки состоит из набора решаемых задач, распределение по процессам и подпроцессам ЖЦ (рис. 1.6).
Рис. 1.6. ЖЦ разработки ПС с конкретизированными задачами
на подпроцессах тестирования
Шаги процесса и отдельные задачи могут выполняться циклически для разных объектов ПС при их тестировании.
Описание семантики задач и шагов процесса тестирования представлено в табл. 1.1.
Таблица 1.1
Состав задач процесса тестирования
Шаг процесса
|
Задачи процесса тестирования
|
1. Создание группы тестирования
|
1.1. Определение участников процесса
тестирования
|
1.2. Распределение обязанностей в группе и формирование плана тестирования
|
2. Анализ риска
|
2.1. Идентификация рисков
|
2.2. Упорядочение рисков
|
2.3. Распределение ресурсов
|
3. Определения целей тестирования
|
3.1. Идентификация целей тестирования
|
3.2. Определения критериев прохождения тестов
|
3.3. Приведения в порядок целей тестирования по оценкам риска
|
4. Разработка планов тестирования
|
4.1. Разработка плана тестирования ПС
|
4.2. Разработка плана интеграционного тестирования
|
4.3. Разработка плана автономного
тестирования
|
4.4. Разработка плана комплексного тестирования
|
5. Разработка тестов
|
5.1. Проектирование и разработка тестов
|
5.2. Подготовка тестовых данных
|
5.3. Проверка тестовых документов
|
6. Автономное и интеграционное тестирование
|
6.1. Автономное тестирование модулей и анализ результатов
|
6.2. Интеграционное тестирование
|
6.3. Повторное тестирование после
устранения дефектов
|
6.4. Анализ результатов интеграционного тестирования
|
7. Тестирования ПС
|
7.1. Утверждение среды и ресурсов
тестирования
|
7.2. Тестирование ПС
|
7.3. Повторное тестирование ПС после
устранения дефектов
7.4. Анализ результатов завершения
тестирования ПС
7.5. Тестирование инсталляции ПС
|
Окончание табл. 1.1
Шаг процесса
|
Задачи процесса тестирования
|
8. Составление документа по тестированию ПС и подготовка отчета
|
8.1. Сбор и анализ данных о результатах тестирования
|
8.2. Подготовка решений и рекомендаций по использованию ПС
|
8.3. Подготовка итогового документа
о результатах тестирования
|
8.4. Проверка решений и подготовка
документа отчета
|
Для подключения задач тестирования ко всем процессам ЖЦ проводится:
распределение обязанностей между участниками процесса с учетом требований относительно их профессиональной подготовки;
определение стандартов на представление окончательных документов, метрик процесса, критериев начала и завершения задач и перехода к следующему шагу процесса;
подбор методов тестирования для выбранного класса ПС для проверки правильности выполнения задач тестирования;
разработка специальных шаблонов документов для документирования процесса тестирования относительно каждого шага процесса тестирования.
При завершении тестирования ПС для определения времени тестирования, стоимости работ учитываются результаты тестирования процесса разработки ПС и оформляется отчетный документ по изготовлению ПС. Оценивание риска отказов проводится на этапе подготовки тестирования и на шагах анализа.
1.3. Типы моделей ЖЦ
Рассмотренные вопросы послужили источником формирования различных видов моделей ЖЦ, основанных на процессном подходе к разработке программных проектов. К широко используемым типам моделей ЖЦ относятся следующие: каскадная, спиральная, инкрементная, эволюционная, стандартизованная и др.
1.3.1. Каскадная модель ЖЦ
Одной из первых стала применяться каскадная модель, в которой каждая работа выполняется один раз и в том порядке, как это представлено в модели (рис. 1.7). То есть делается предположение, что каждая работа будет выполнена настолько тщательно, что после ее завершения и перехода к следующему этапу возвращения к предыдущему не потребуется.
Рис. 1.7. Каскадная модель ЖЦ программных систем
Разработчик проверяет промежуточный результат разными известными методами верификации и фиксирует его в качестве готового эталона для следующего процесса.
Согласно данной модели ЖЦ работы и задачи процесса разработки обычно выполняются последовательно, как это представлено в схеме. Однако вспомогательные и организационные процессы (контроль требований, управление качеством и др.) обычно выполняются параллельно с процессом разработки. В данной модели возвращение к начальному процессу предусматривается после сопровождения и исправления ошибок.
Особенность такой модели состоит в фиксации последовательных процессов разработки программного продукта. В ее основу положена модель фабрики, где продукт проходит стадии от замысла до производства, затем передается заказчику как готовое изделие, изменение которого не предусмотрено, хотя возможна замена на другое подобное изделие в случае рекламации или некоторых ее деталей, вышедших из строя.
Недостатки этой модели:
процесс создания ПС не всегда укладывается в такую жесткую форму и последовательность действий;
не учитываются изменившиеся потребности пользователей, изменения во внешней среде, которые вызовут изменения требований к системе в ходе ее разработки;
большой разрыв между временем внесения ошибки (например, на этапе проектирования) и временем ее обнаружения (при сопровождении), что приводит к большой переделке ПС.
При применении каскадной модели имеют место следующие факторы риска:
требования к ПС недостаточно четко сформулированы, либо не учитывают перспективы развития ОС, сред и т.п.;
большая система, не допускающая компонентной декомпозиции, может вызвать проблемы с размещением ее в памяти или на платформах, не предусмотренных в требованиях;
внесение быстрых изменений в технологию и в требования может ухудшить процесс разработки отдельных частей системы или системы в целом;
ограничения на ресурсы (человеческие, программные, технические и др.) в ходе разработки могут сузить отдельные возможности реализации системы;
Полученный продукт может оказаться плохим для применения по причине недопонимания разработчиками требований или функций системы или недостаточно проведенного тестирования.
Преимущества реализации системы с помощью каскадной модели следующие:
все задачи подсистем и системы реализуются одновременно (ни одна задача не забыта), что способствует установлению стабильных связей и отношений между ними;
полностью разработанную систему с документацией на нее легче сопровождать, тестировать, фиксировать ошибки и вносить изменения не беспорядочно, а целенаправленно, начиная с требований (например, добавить или заменять некоторые функции) и повторить процесс.
Каскадную модель можно рассматривать как модель ЖЦ, пригодную для создания первой версии ПО с целью проверки реализованных в ней функций. При сопровождении и эксплуатации могут быть обнаружены разного рода ошибки, исправление которых потребует повторного выполнения всех процессов, начиная с уточнения требований.
1.3.2. Инкрементная модель ЖЦ
Первая создаваемая промежуточная версия системы (выпуск 1) реализует часть требований, в последующую версию (выпуск 2) добавляют дополнительные требования и так до тех пор, пока не будут окончательно выполнены все требования и решены задачи разработки системы. Для каждой промежуточной версии на этапах ЖЦ выполняются необходимые процессы, работы и задачи, в том числе, анализ требований и создание новой архитектуры, которые могут быть выполнены одновременно (рис. 1.8).
Рис. 1.8. Инкрементная модель ЖЦ
Процессы разработки технического проекта ПС, его программирование и тестирование, сборка и квалификационные испытания ПС выполняются при создании каждой последующей версии.
В соответствии с данной моделью ЖЦ, процессы которой практически такие же, что и в каскадной модели, ориентир делается на разработку некоторой законченной промежуточной версии, а задачи процесса разработки выполняются последовательно или частично параллельно для ряда отдельных промежуточных структур версии.
Работы и задачи процесса разработки следующей версии системы с дополнительными требованиями или функциями могут выполняться неоднократно в той же последовательности для всех промежуточных версий системы. Процессы сопровождения и эксплуа-тации могут быть реализованы параллельно с процессом разработки версии путем проверки частично реализованных требований в каждой промежуточной версии и так до получения законченного варианта системы. Вспомогательные и организационные процессы ЖЦ обычно выполняются параллельно с процессом разработки версии системы и к концу разработки будут собраны данные, на основании которых может быть установлен уровень завершенности и качества изготовленной системы.
При применении данной модели необходимо учитывать следующие факторы риска:
требования составлены с учетом возможности их изменения при реализации продукта;
все возможности системы требуется реализовать сначала;
быстрое изменение технологии и требований к системе может привести к нарушению полученной структуры системы;
ограничения в ресурсном обеспечении (исполнители, финансы) могут привести к затягиванию сроков сдачи системы в эксплуатацию.
Данную модель целесообразно использовать, в случаях когда:
желательно реализовать некоторые возможности системы быстро за счет создания промежуточной версии продукта;
система декомпозируется на отдельные составные части, которые можно реализовывать как некоторые самостоятельные промежуточные или готовые продукты;
возможно увеличение финансирования на разработку отдельных частей системы.
1.3.3. Спиральная модель
Принципиальной особенностью спиральной модели является следующее: прикладное программное обеспечение создается не сразу, как в случае каскадного подхода, а по частям с использованием метода прототипирования. Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого программного обеспечения (рис. 1.9).
Рис. 1.9. Спиральная модель ЖЦ разработки программных систем
Создание прототипов осуществляется в несколько итераций, или витков спирали. Каждая итерация соответствует созданию фрагмента или версии программного обеспечения, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации (рис. 1.10) производится тщательная оценка риска превышения сроков и стоимости проекта, чтобы определить необходимость выполнения еще одной итерации, степень полноты и точности понимания требований к системе, а также целесообразность прекращения проекта. Спиральная модель избавляет пользователей и разработчиков программного обеспечения от необходимости полного и точного формулирования требований к системе на начальной стадии, поскольку они уточняются на каждой итерации. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.
Рис. 1.10. Спиральная модель жизненного цикла
программного обеспечения
Спиральная модель не исключает использования каскадного подхода на завершающих стадиях проекта в тех случаях, когда требования к системе оказываются полностью определенными.
Основная проблема спирального цикла – определение момента перехода на следующую стадию. Для ее решения необходимо ввести временные ограничения на каждую из стадий жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
Достоинствами спиральной модели являются:
ускорение разработки (раннее получение результата за счет прототипирования);
постоянное участие заказчика в процессе разработки;
разбиение большого объема работы на небольшие части;
снижение риска (повышение вероятности предсказуемого поведения системы).
Спиральная модель не исключает использования каскадного подхода на завершающих стадиях проекта в тех случаях, когда требования к системе оказываются полностью определенными.
К недостаткам спиральной модели можно отнести:
сложность планирования (определения количества и длительности итераций, оценки затрат и рисков);
сложность применения модели с точки зрения менеджеров и заказчиков (из-за привычки к строгому и детальному планированию);
напряженный режим работы для разработчиков (при краткосрочных итерациях).
Основная проблема спирального цикла – определение момента перехода на следующую стадию. Для ее решения необходимо ввести временные ограничения на каждую из стадий жизненного цикла.
Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
При необходимости внесения изменений в систему на каждом витке с целью получения новой версии системы обязательно вносятся изменения в предварительно зафиксированные требования, после чего происходит возврат на предыдущий виток спирали для продолжения реализации новой версии системы с учетом изменений.
1.3.4. Эволюционная модель жизненного цикла
В случае эволюционной модели система разрабатывается в виде последовательности блоков структур (конструкций). В отличие от инкрементной модели ЖЦ подразумевается, что требования устанавливаются частично и уточняются в каждом последующем промежуточном блоке структуры системы.
Использование эволюционной модели предполагает проведение исследования предметной области для изучения потребностей заказчика проекта и анализа возможности применения этой модели для реализации. Модель применяется для разработки несложных и не критических систем, для которых главным требованием является реализация функций системы. При этом требования не могут быть определены сразу и полностью. Тогда разработка системы проводится итерационно путем ее эволюционного развития с получением некоторого варианта системы – прототипа, на котором проверяется реализация требований. Иными словами, такой процесс по своей сути является итерационным, с повторяющимися этапами разработки, начиная от измененных требований и до получения готового продукта. В некотором смысле к этому типу модели можно отнести спиральную модель.
Развитием этой модели является модель эволюционного прототипирования в рамках всего ЖЦ разработки (рис. 1.10). В литературе она часто называется моделью быстрой разработки приложений RAD (Rapid Application Development). В данной модели приведены действия, которые связаны с анализом ее применимости для конкретного вида системы, а также обследование заказчика для определения потребностей пользователя для разработки плана создания прототипа.
В модели есть две главные итерации разработки функционального прототипа, проектирования и реализации системы. Проверяется, удовлетворяет ли она всем функциональным и нефункциональным требованиям. Основной идеей этой модели является моделирование отдельных функций системы в прототипе и постепенное эволюционная его доработка до выполнения всех заданных функциональных требований.
Рис. 1.11. Модель эволюционного прототипирования
Итераций по получению промежуточных вариантов прототипа может быть несколько, в каждой из которых добавляется функция и повторно моделируется работа прототипа. И так до тех пор, пока не будут промоделированы все функции, заданные в требованиях к системе. Потом выполняется еще итерация – окончательное программирование для получения готовой системы.
Эта модель применяется для систем, в которых наиболее важными являются функциональные возможности, и которые необходимо быстро продемонстрировать на CASE-средствах.
Так как промежуточные прототипы системы соответствуют реализации некоторых функциональных требований, то их можно проверять и при сопровождении и эксплуатации, т.е. параллельно с процессом разработки очередных прототипов системы. При этом вспомогательные и организационные процессы могут выполняться параллельно с процессом разработки и накапливать сведения по данным количественных и качественных оценок на процессах разработки.
При этом учитываются такие факторы риска:
реализация всех функций системы одновременно может привести к громоздкости;
ограниченные человеческие ресурсы заняты разработкой в течение длительного времени.
Преимущества применения данной модели ЖЦ следующие:
быстрая реализация некоторых функциональных возможностей системы и их апробирование;
использование промежуточного продукта в следующем прототипе;
выделение отдельных функциональных частей для реализации их в виде прототипа;
возможность увеличения финансирования системы;
обратная связь устанавливается с заказчиком для уточнения функциональных требований;
упрощение внесения изменений в связи с заменой отдельной функции.
Модель развивается в направлении добавления нефункциональных требований к системе, связанных с защитой и безопасностью данных, несанкционированным доступом к ним и др.
1.3.5. Стандартизация модели жизненного цикла
Типичный ЖЦ системы начинается с формулировки идеи или потребности, проходит все процессы разработки, производства, эксплуатации и сопровождения системы. Стандартный ЖЦ состоит из процессов, каждый процесс характеризуется видами деятельности и задачами, которые выполняются на нем. Переход от одного процесса к другому должен быть санкционирован и определены входные и выходные данные.
Модель данного ЖЦ включает в себя следующие процессы:
определение требований;
разработка (проектирование, конструирование);
верификация, валидация, тестирование;
изготовление;
эксплуатация;
сопровождение.
Данной модели соответствуют все виды деятельности, начиная с разработки проекта или концепции программного продукта и заканчивая его изготовлением. Как было сказано выше, стандарт ISO/IEC 12207 объединяет эти виды деятельности в следующие три категории: основные, организационные и вспомогательные процессы, которые и составляют стандартный ЖЦ.
Процессы приобретения, поставки и разработки используются для анализа и определения системных требований и решений верхнего уровня проектирования системы и предварительного определения требований к компонентам системы, включая ПО. Процесс разработки может быть использован для анализа, демонстрации, прототипирования требований и проектных решений.
На этапе проектирования разрабатывается техническое, программное, организационное обеспечение системы, а также проектируются, разрабатываются, интегрируются, тестируются и оцениваются ее компоненты. Результатом этого процесса является система, которая разрабатывалась согласно контракту или договора.
Стандарт разработан так, чтобы его можно было применить полностью или частично. Действия и задачи основных процессов отбираются, адаптируются и применяются при разработке или модификации системы. Процесс разработки может включать одну или более итераций. Результатом являются требования к ПО, проект и реализованный продукт.
Если разрабатываемое ПО – часть системы, то к ней могут применяться все действия процессов разработки, и если эта часть – автономное ПО, то некоторые общие действия на уровне системы могут не использоваться при его разработке.
Во время процесса изготовления система готовится для поставки заказчику и покупателям. Цель процесса – тиражирование (производство) и установка работающей системы у заказчика для сопровождения. Данный процесс заключается в копировании изготовленного продукта и документации на соответствующие носители пользователей. К видам деятельности на процессе относится достижение качества реализации и создания конфигурации (версии) системы. Другие вспомогательные процессы и действия (например, сбор данных о результатах контроля) могут применяться по мере необходимости.
Изготовленная система, начиная с первой ее версии, передается заказчику или продается желающим покупателям. Другие процессы (приобретения, поставки и разработки) могут использоваться при инсталляции и проверке разработанной или модифицированной системы.
Процесс эксплуатации включает использование системы ее покупателями. Когда система больше не удовлетворят пользователей, она утилизируется, т.е. удаляются из употребления путем уничтожения кодов, архивов, процедур и т.п.
Во время сопровождения система модифицируется вследствие обнаруженных ошибок и недостатков в ее разработке либо по требованиям пользователя, который желает ее адаптировать к новой среде или усовершенствовать отдельные ее функции.
|
