Главная / Пособия / Жизненный цикл программных систем. Процессы жизненного цикла программного обеспечения Стандарт ieee 90 элементы сопровождения
06.03.2024

Жизненный цикл программных систем. Процессы жизненного цикла программного обеспечения Стандарт ieee 90 элементы сопровождения

Структура ЖЦ ПО в соответствии со стандартом ISO/IEC 12207 базируется на трех группах процессов (рис. 1):

· основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

· вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);

· организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

Рис. 1. Процессы жизненного цикла программного обеспечения.

Процесс приобретения (acquisition process). Он состоит из действий

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

1) инициирование приобретения;

2) подготовку заявочных предложений;

3) подготовку и корректировку договора;

4) надзор за деятельностью поставщика;

5) приемку и завершение работ.

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

1) инициирование поставки;

2) подготовку ответа на заявочные предложения;

3) подготовку договора;

4) планирование;

5) выполнение и контроль;

6) проверку и оценку;

7) поставку и завершение работ.

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

Процесс разработки включает следующие действия:

1) анализ требований к системе;

2) проектирование архитектуры системы;

3) анализ требований к ПО;

4) проектирование архитектуры ПО;



5) детальное проектирование ПО;

6) кодирование и тестирование ПО;

7) интеграцию ПО;

8) квалификационное тестирование ПО;

9) интеграцию системы;

10) квалификационное тестирование системы;

11) установку ПО;

12) приемку ПО.

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

1) эксплуатационное тестирование;

2) эксплуатацию системы;

3) поддержку пользователей.

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

требованиям. Изменения, вносимые в существующее ПО, не должны нарушать

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

Процесс сопровождения охватывает следующие действия:

1) анализ проблем и запросов на модификацию ПО;

2) модификацию ПО;

3) проверку и приемку;

4) перенос ПО в другую среду;

5) снятие ПО с эксплуатации.

В группу вспомогательных процессов включены:

Документирование;

Управление конфигурацией; обеспечение качества;

Верификация; аттестация;

Совместная оценка;

Разрешение проблем.

Процесс документирования (documentation process). Он предусматривает формализованное описание информации, созданной в течение ЖЦ ПО. Процесс документирования включает следующие действия:

1) проектирование и разработку;

2) выпуск документации;

3) сопровождение документации.

Процесс управления конфигурацией (configuration management process). Он предполагает применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО в системе, управления модификациями ПО, описания и подготовки отчетов о состоянии компонентов ПО и запросов на модификацию, обеспечения полноты, совместимости и корректности компонентов ПО, управления хранением и поставкой ПО. Согласно стандарту IEEE-90 под конфигурацией ПО понимается совокупность его функциональных и физических ха-

рактеристик, установленных в технической документации и реализованных в ПО.

Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации по управлению конфигурацией ПО отражены в проекте стандарта ISO/I EC CD 12207-2: 1995 "Information Technology - Software Life Cycle Processes. Part 2.

Configuration Management for Software". Процесс управления конфигурацией включает следующие действия:

1) идентификацию конфигурации;

2) контроль конфигурации;

3) учет состояния конфигурации;

4) оценку конфигурации;

5) управление выпуском и поставку.

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

1) обеспечение качества продукта;

2) обеспечение качества процесса;

3) обеспечение прочих показателей качества системы.

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

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

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

Процесс аудита (audit process). Он представляет собой определение соответствия требованиям, планам и условиям договора.

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

В группу организационных процессов ЖЦ ПО входят:

Управление;

Создание инфраструктуры;

Усовершенствование;

Выпуск новых версий;

Обучение.

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

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

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

персонала.

Процесс обучения (training process). Он охватывает первоначальное обучение и последующее постоянное повышение квалификации персонала.

В области ИТ наиболее значимые с точки зрения практики стандарты публикуются следующими организациями:

  • Институт инженеров по электротехнике и радиоэлектронике (IEEE, www.ieee.org) в течение многих лет остается лидирующей научно-технической организацией, в том числе, в создании стандартов документации программного обеспечения. Большинство стандартов разработаны различными комитетами, состоящими из опытных и ответственных инженеров-профессионалов. Некоторые из стандартов IEEE стали также стандартами ANSI (American National Standards Institute). Преимущественно стандарты IEEE легли в основу при составлении МУ по КП. Schmidt M. Implementing the IEEE Software Engineering Standards.
  • Международная организация по стандартизации (ISO) имеет огромное влияние во всем мире, особенно среди организаций производителей, имеющих дело с Евросоюзом (ЕС). В настоящее время фактически все современные стандарты в области ИТ, переведенные и принятые в РФ – это стандарты, подготовленные ISO совместно с международной электротехнической комиссией – МЭК (IEC). Вы знаете, что особое внимание уделяется вопросам обеспечения качества продукции на международном уровне, поэтому, согласно постановления правительства РФ №113 от 02.02.1998 соблюдение требований ISO 9000 (серия стандартов, регламентирующих управление качеством (менеджмент качества) на предприятиях) – обязательное условие для получения госзаказа.
  • Институт технологий разработки программного обеспечения (Software Engineering Institute – SEI, sei.cmu.edu – более 1000 статей) был учрежден Министерством обороны США в университете Карнеги-Меллон для поднятия уровня технологии программного обеспечения у подрядчиков Министерства обороны. Работа SEI также была принята многими коммерческими компаниями, которые считают улучшение процесса разработки программного обеспечения своей стратегической корпоративной задачей. Мы обратимся к одному из стандартов, разработанному SEI, который называется Моделью зрелости возможностей (СММ).
  • Консорциум по технологии манипулирования объектами (Object Management Group, www.omg.org) является некоммерческой организацией, в которую в качестве членов входят около 700 компаний. OMG устанавливает стандарты для распределенных объектно-ориентированных вычислений. Нужно заметить, что OMG использует унифицированный язык моделирования UML в качестве своего стандарта для описания проектов. UML мы будем изучать детально, т.к. использование этого языка совместно с унифицированным процессом фирмы Rational является основой при проработке ядра курсового проекта.

Понятие жизненного цикла системы

Необходимость стандартизации разработки программного обеспечения наиболее удачно описана во введении стандарта ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы жизненного цикла программных средств» : «Программное обеспечение является неотъемлемой частью информационных технологий и традиционных систем, таких, как транспортные, военные, медицинские и финансовые. Имеется множество разнообразных стандартов, процедур, методов, инструментальных средств и типов операционной среды для разработки и управления программным обеспечением. Это разнообразие создает трудности при проектировании и управлении программным обеспечением, особенно при объединении программных продуктов и сервисных программ. Стратегия разработки программного обеспечения требует перехода от этого множества к общему порядку, который позволит специалистам, практикующимся в программном обеспечении, «говорить на одном языке» при разработке и управлении программным обеспечением. Этот международный стандарт обеспечивает такой общий порядок».

Стандарт ГОСТ Р ИСО/МЭК 12207-99 определяет базовое понятие программной системы – «жизненный цикл» (ГОСТ Р ИСО/МЭК ТО 15271-2002 «Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207»).

ГОСТ Р ИСО/МЭК 12207-99 вводит понятие модели жизненного цикла как структуры, состоящей из процессов, и охватывающей жизнь системы от установления требований к ней до прекращения ее использования. Предлагается это определение подкорректировать и разделить на два определения:

  1. жизненный цикл – совокупность процессов, разделенных на работы и задачи, и включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающих жизнь системы от установления требований к ней до прекращения ее использования.
  2. модель жизненного цикла – структура, определяющая последовательность осуществления процессов, работ и задач, выполняемых на протяжении жизненного цикла программной системы, а также взаимосвязи между ними.

Процессы ЖЦ разделены на три группы: основные, вспомогательные и организационные.

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

Рисунок – Основные процессы ЖЦ ИС

Группа вспомогательных процессов включает в себя процессы, обеспечивающие выполнение основных процессов:

  • документирование;
  • управление конфигурацией;
  • обеспечение качества;
  • верификация;
  • аттестация;
  • оценка;
  • аудит;
  • решение проблем.

Группа организационных процессов включает в себя процессы:

  • управление проектами;
  • создание инфраструктуры проекта;
  • определение, оценка и улучшение самого ЖЦ;
  • обучение.

В тексте ГОСТ 12207-99 работы, входящие в состав основных, вспомогательных и организационных процессов охарактеризованы очень общо, фактически намечены только их направления, поэтому для того, что бы приступить к проектированию понадобятся стандарты и дополнительная литература, раскрывающая содержание каждого отдельного процесса или, что еще лучше, отдельной работы.
Из группы основных процессов наибольший интерес представляет процесс разработки.
Следует отметить, что ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» процесс создания автоматизированной системы разделяет на следующие стадии:

  • формирование требований к АС,
  • разработка концепции АС,
  • техническое задание,
  • эскизный проект,
  • технический проект,
  • рабочая документация,
  • ввод в действие,
  • сопровождение.

Стадии разделены на этапы, содержание которых перекликается с содержанием рядя задач, описанных в ГОСТ 12207-99.

Процесс разработки

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

Рисунок – Структура процесса разработки

Подготовительная работа

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

Анализ требований

Анализ требований к ПС предполагает определение следующих характеристик для каждого компонента ПС:

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

Проектирование архитектуры

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

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

Детальное проектирование

ПС включает следующие задачи:

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

Кодирование и тестирование

ПС охватывают следующие задачи:

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

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

ГОСТ Р ИСО/МЭК 12119-2000 «Информационная технология. Пакеты программ. Требования к качеству и тестирование» содержит указания, которые определяют порядок тестирования продукта на соответствие его требованиям к качеству. Тестирование является трудоемким процессом. Согласно оценкам некоторых специалистов процентное
распределение времени между процессами проектирование – разработка – тестирование находится в отношении 40-20-40. В этой связи широкое распространение получают системы автоматизации тестирования. В стандарте IEEE 1209-1992 «Recommended Practice for the Evaluation and Selection of CASE Tools» сформулированы общие требования к функциям средств автоматизации тестирования.

Интеграция системы

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

Установка системы

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

Приемка системы

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

Модели жизненного цикла программного средства

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

К настоящему времени наибольшее распространение получили две основные модели жизненного цикла:

  • каскадная (водопадная) модель;
  • спиральная модель.

Каскадная модель

Каскадная модель демонстрирует классический подход к разработке различных систем в различных прикладных областях. Для разработки информационных систем данная модель широко использовалась в 70-х и первой половине 80-х годов. Именно каскадная модель положена в основу ГОСТ серии 34.xxx и стандарта Министерства обороны США DOD-STD-2167A. Процессы ГОСТ 12207-99 в ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» названы стадиями и немного различаются по составу.
Каскадная модель предусматривает последовательную организацию процессов. Причем переход к следующему процессу происходит только после того, как полностью завершены все работы на предыдущем. Каждый процесс завершается выпуском полного комплекта документации, достаточной для того, чтобы работа могла быть продолжена другой командой разработчиков.

Главный недостаток каскадной модели заключается в том, что ошибки и недоработки на любом из этапов проявляются, как правило, на последующих этапах работ, что приводит к необходимости возврата назад. По сведениям консалтинговой компании The Standish Group в 1998 г. в США более 28 % проектов корпоративных информационных систем (IT-проектов) заканчивались неудачей; почти 46% IT-проектов завершались с перерасходом бюджета (в среднем на 189%); и только 26% проектов укладывается и в выделенный срок, и бюджет.

Кроме того, к недостаткам каскадной модели следует отнести:

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

Спиральная модель

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

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

Быстрая разработка приложений

В 90-е годы XX века на основе спиральной модели была основана практическая технология, получившая название «быстрая разработка приложения» - RAD (Rapid Application Development). При этом ЖЦ состоял из четырех стадий:

  • анализ и планирование требований,
  • проектирование,
  • реализация,
  • внедрение.

Основные принципы RAD:

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

В начале 2001 г. ряд ведущих специалистов в области программной инженерии (Мартин Фаулер, Кент Бек и др.) сформировали группу под названием Agile Alliance для поддержания и развития нового подхода к проектированию – «быстрая разработка ПО» (Agile Software Development). Одной из реализаций этого подхода является «Экстремальное программирование» (Extreme Programming - XP).

Принципы экстремального программирования заключаются в следующем:

  1. В команде работает от трех до десяти программистов. Один или несколько заказчиков должны иметь возможность непрерывного обеспечения текущей экспертизы.
  2. Программы разрабатываются трехнедельными итерациями. На каждой итерации производится работающий, протестированный код, который может сразу использоваться заказчиками. Собранная система переправляется к конечным пользователям в конце каждого периода выпуска версий, который может занимать от двух до пяти итераций.
  3. Единицей собираемых требований к ПО является «пользовательская история» (user story), записанная на индексной карточке, и, описывающая с точки зрения пользователя функциональность, которая может быть разработана за одну итерацию. Заказчики и программисты планируют работы на следующей итерации таким образом:
    • программисты оценивают время для завершения работы с каждой карточкой;
    • заказчики расставляют приоритеты, изменяют и пересматривают их при необходимости. Разработка истории начинается с ее обсуждения программистами и экспертом-заказчиком.
  4. Программисты работают парами и следуют строгим стандартам кодирования, установленным ими в начале проекта. Они создают модульные тесты для всего, что они пишут, и добиваются, чтобы эти тесты выполнялись каждый раз при сдаче кода на обязательный контроль версий и в систему управления конфигурацией.
  5. В то время как программисты работают, заказчики посещают программистов, чтобы прояснять идеи, пишут приемочные тесты системы для прогона во время итерации и в ее конце выбирают истории для реализации в следующей итерации.
  6. Каждый день команда проводит оперативные совещания, на которых программисты рассказывают, над чем они работают, что продвигается хорошо и в чем требуется помощь. В конце каждой итерации проводится другое совещание, на котором они оценивают, что было сделано хорошо, и над чем нужно работать в следующий раз. Этот перечень вывешивается, чтобы все могли его видеть, работая во время следующей итерации.
  7. Один человек в команде назначается «наставником». Вместе с участниками команды он оценивает использование ими основных приемов: парного программирования и тестирования, ротации пар, поддержания простоты проектных решений, коммуникации и т.д. с целью постоянного совершенствования процесса разработки.

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

  • С – дефекты вызывают потерю удобства;
  • D – дефекты вызывают потерю возместимых средств (материальных или финансовых);
  • Е – дефекты вызывают потерю невозместимых средств;
  • L – дефекты создают угрозу человеческой жизни.

Масштаб определяется количеством разработчиков, участвующих в проекте:

  • от 1 до 6 человек – малый масштаб;
  • от 6 до 20 человек – средний масштаб;
  • свыше 20 человек – большой масштаб.

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

Унифицированный процесс разработки ПО

В настоящее время продолжаются работы по созданию некоторого универсального процесса разработки ИС. В 1999г. сотрудниками компании Rational Айваром Джекобсоном, Гради Бучем и Джеймсом Рамбо была издана книга Unified Software Development Process (Унифицированный процесс разработки ПО), которая была переведена на русский язык и издана издательством «Питер» в 2002. Унифицированный процесс представляет собой попытку объединения водопадной и итеративной моделей ЖЦ.

При этом, ЖЦ разделен на 4 фазы:

  1. Начало (inception): осуществляется первичная оценка проекта.
    • создается упрощенная модель вариантов использования, содержащая наиболее критичные с точки зрения реализации прецеденты;
    • создается пробный вариант архитектуры, содержащей наиболее важные подсистемы;
    • проводится идентификация и определение приоритетов рисков;
    • планируется фаза проектирования;
    • грубо оценивается весь проект в целом;
  2. уточнение (elaboration): детально описываются большинство вариантов использования и разрабатывается архитектура системы. В конце фазы проектирования менеджер проекта выполняет подсчет ресурсов, необходимых для завершения проекта. Необходимо ответить на вопрос: достаточно ли проработаны варианты использования, архитектура и план, чтобы можно было бы давать контрактные обязательства на выполнение работы и переходить к подготовке и подписанию «Технического задания»?;
  3. построение (construction) – создание продукта. В конце этой фазы продукт включает в себя все варианты использования, которые разработчики и заказчик решили включить в текущий выпуск;
  4. внедрение (transition) – выпуск продукта. Проводится тестирование бета-версии продукта отделом тестирования компании и одновременно организуется пробная эксплуатация системы пользователями. После этого разработчики исправляют обнаруженные ошибки и вносят некоторые из предложенных улучшений в главный выпуск, подготавливаемый для широкого распространения.

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

  • определение требований (ОТ);
  • анализ (А);
  • проектирование (П);
  • реализация (Р);
  • тестирование (Т).

К дополнительным рабочим потокам могут относиться:

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

Рисунок - Модель ЖЦ согласно унифицированного процесса разработки ПО

Выбор модели ЖЦ во многом зависит от типа и масштаба разрабатываемой системы. Для разработки большинства АСОИУ со свободным временем применима итерационная модель ЖЦ, в то время как для систем реального времени больше подходит водопадная модель. На лекциях при проработке вопросов проектирования ИС особое внимание мы уделим использованию Унифицированного языка моделирования (UML), а поскольку его создателями являются Гради Буч и Джеймс Рамбо, то мы будем обращаться и к идеологии Унифицированный процесс разработки.

Рисунок – Нормативные документы, сопровождающие процесс разработки

Вспомогательные процессы жизненного цикла

Процесс обеспечения качества

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

Рисунок – Структура вспомогательных процессов ЖЦ

В контексте ГОСТ Р ИСО/МЭК 9126-93. «Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению» под характеристикой качества понимается «набор свойств (атрибутов) программной продукции, по которым ее качество описывается и оценивается».

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

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

ГОСТ 28195-89 «Оценка качества программных средств. Общие положения» на верхнем, первом, уровне выделяет 6 показателей – факторов качества: надежность, корректность, удобство применения, эффективность, универсальность и сопровождаемость. Эти факторы детализируются в совокупности 19 критериями качества на втором уровне. Дальнейшая детализация показателей качества представлена метриками и оценочными элементами, которых насчитывается около 240. Каждый из них рекомендуется экспертно оценивать в пределах от 0 до 1. Состав используемых факторов, критериев и метрик предлагается выбирать в зависимости от назначения, функций и этапов жизненного цикла ПС.

В стандарте ГОСТ 28806-90 «Качество программных средств. Термины и определения» формализуются общие понятия программы, программного средства, программного продукта и их качества. Даются определения 18 наиболее употребляемых терминов, связанных с оценкой характеристик программ. Уточнены понятия базовых показателей качества, приведенных в ГОСТ 28195-89.
Вопрос обеспечения качества ПС требует особого внимания, поскольку согласно постановления правительства РФ №113 от 02.02.1998 соблюдение требований международного стандарта обеспечения и управления качеством ISO 9000 – обязательное условие для получения госзаказа.
На современном этапе недостаточно иметь только методы оценки качества произведенного и используемого программного средства (выходной контроль), необходимо иметь возможность планировать качество, измерять его на всех этапах жизненного цикла программного средства и корректировать процесс производства программного обеспечения для улучшения качества.

Стандарты серии ISO 9000 являются слишком общими. Каждая компания, производящая программное обеспечение и желающая внедрить у себя действенную систему управления качеством на основе стандартов ISO 9000-й серии, должна учесть специфику своей отрасли и разработать систему показателей качества, которая бы отражала реальное влияние факторов качества на программный продукт. С этой целью многие организации определили процесс раздельной систематической и полной проверки – контроль качества (Quality Assurance), который начинается вместе с запуском проекта, предусматривает инспектирование и тестирование и проводится в идеале некоторой независимой организацией. В действительности, чаще всего, контроль качества проводится группой коллег автора работы.
Цель инспектирования состоит в проверке частей проекта на наличие дефектов:

  • документации,
  • требований,
  • результатов анализа,
  • проектирования,
  • листингов и т.д.

Актуальность инспектирования показывает сравнение стоимости и обнаружения и исправления дефекта во время инспектирования и во время интеграции по данным Fagin, M., «Design and Code Inspections to Reduce Errors in Program Development, IBM Systems Journal. Некоторые авторы считают эти данные весьма заниженными.

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

Для проведения инспектирования требуется выполнение следующих шагов:

  1. Процесс инспектирования начинается с планирования. Разрабатывается классификация дефектов по описанию, степени серьезности и типу. Выполняется выбор метрик, по которым будет проводиться инспектирование, выбор инструментов для сбора и анализа полученных данных, а также распределение ролей между проверяющими:
    • Ведущий ответственен за правильное проведение инспектирования.
    • Корректор отвечает за деятельность команды и направляет ее в нужное русло. Корректор принимает участие в инспектировании.
    • Регистратор отвечает за учет описания и классификацию дефектов, как это принято в команде. Регистратор также участвует в инспектировании.
    • Специализированный инспектирующий – специалист в некоторой узкой области, к которой принадлежит инспектируемый фрагмент.
  2. При необходимости может быть организован обзорный семинар для лучшего понимания объекта инспектирования.
  3. Проведение инспектирования. Инспектирующие проверяют работу в полном объеме на своих рабочих местах (например, проверяют, соответствует ли инспектируемый программный код детальному проекту). Инспектирующие обычно заносят все дефекты в базу данных (например, доступную через сеть) вместе с описаниями и классификацией. Инспектируемые части системы должны быть логически завершенными.
  4. Проводится инспекционное собрание, в ходе которого участники представляют свои результаты.
  5. Автор исправляет дефекты (фаза доработки).
  6. На окончательном собрании по завершению работы корректор и автор убеждаются в том, что все дефекты исправлены. Однако это не предполагает детальной ревизии всей работы корректором. Все исправления остаются на совести автора, ответственного за свою работу.
  7. Как и после других процессов, группа встречается для обсуждения самого процесса инспектирования и решает, как он может быть улучшен.

В компании ведется учет времени, потраченного на инспектирование и объема проверенной работы с целью их дальнейшего использования при оценке инспектирования в будущем. В условиях жесткого временного ограничения используется т.н. система «опеки», при которой каждый член команды опекается своим коллегой.
Для учета всех факторов контроля качества удобно пользоваться списками контрольных вопросов. Такие списки содержат пункты, которые необходимо последовательно проверить.
Например, план контроля качества программного обеспечения (Software Quality Assurance Plan – SQAP) в соответствии со стандартом IEEE 739-1989 определяет:

  • кто будет нести ответственность за качество – физическое лицо, менеджер, группа, организация и т.п.;
  • какая документация требуется;
  • какие методы будут использоваться для гарантии качества – инспектирование, тестирование и т.д.;
  • какие мероприятия должны быть проведены в ходе управления процессом – собрания, аудиты, обзоры и т. п.

Надежность и безопасность

Одной из наиболее значимых характеристик, входящих в понятие качество, является свойство надежности.
По определению, установленному в ГОСТ 13377-75 «Надежность в технике. Термины и определения», надежность – свойство объекта выполнять заданные функции, сохраняя во времени значения установленных эксплуатационных показателей в заданных пределах, соответствующих заданным режимам и условиям использования, технического обслуживания, ремонта, хранения и транспортирования. Таким образом, надежность является внутренним свойством системы, заложенным при ее создании и проявляющимся во времени при функционировании и эксплуатации.
Надежность функционирования ПС наиболее широко характеризуется устойчивостью, или способностью к безотказному функционированию, и восстанавливаемостью работоспособного состояния после произошедших сбоев или отказов.
Контроль надежности и безопасности создаваемых и модифицируемых программ должен сопровождать весь жизненный цикл ПС посредством специально организованной эффективной технологической системы обеспечения их качества. Проверка и подтверждение качества сложных и критических ПС должна обеспечиваться сертификацией аттестованными проблемно-ориентированными сертифицированными лабораториями.

Стандарты в области информационной безопасность делят на две группы:

  • оценочные стандарты, предназначенные для оценки и классификации ИС и средств защиты по требованиям безопасности – стандарт Министерства обороны США «Критерии оценки доверенных компьютерных систем», «Гармонизированные критерии Европейских стран», международный стандарт «Критерии оценки безопасности информационных технологий», Руководящие документы Гостехкомиссии России;
  • спецификации, регламентирующие различные аспекты реализации и использования средств и методов защиты, публикуемые «Тематической группой по технологии Internet» (Internet Engineering Task Force, IETF) и ее подразделений – рабочей группой по безопасности.

К наиболее значимым оценочным стандартам можно отнести:

  • Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации. – Москва, 1997 – классифицирует межсетевые экраны в соответствие с уровнем фильтрации потока данных эталонной семиуровневой модели.
  • ИСО/МЭК 15408:1999 «Критерии оценки безопасности информационных технологий».

Ко второй группе можно отнести следующие документы:

  • Х.800 «Архитектура безопасности для взаимодействия открытых систем». Выделены основные сетевые сервисы безопасности: аутентификация, управление доступом, обеспечение конфиденциальности и/или целостности данных. Для реализации сервисов предусмотрены следующие сетевые механизмы безопасности и их комбинации: шифрование, электронная цифровая подпись, управление доступом, контроль целостности данных, аутентификация, дополнение трафика, управление маршрутизацией, нотаризация.
  • Спецификация Internet-сообщества RFC 1510 «Сетевой сервис аутентификации Kerberos (V5)» рассматривает проблему аутентификации в разнородной распределенной среде с поддержкой концепции единого входа в сеть;
  • Х.500 «Служба директорий: обзор концепций, моделей и сервисов», Х.509 «Служба директорий: каркасы сертификатов открытых ключей и атрибутов».

Процессы верификации, аттестации и аудита

Верификация, аттестация и аудит являются составной частью плана контроля качества SQAP IEEE 739-1989.
Верификация отвечает на вопрос: «Делаем ли мы на данном этапе то, что запланировано?». Аттестация и аудит отвечает на вопрос: «Отвечает ли строящийся объект нуждам заказчика?».
Стандарт IEEE 1012-1986 Software Verification and Validation Plan (SVVP) объединяет процессы аттестации и аудита под названием валидация и определяет порядок их проведения.

В процессе верификации проверяются следующие условия:

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

Процесс совместной оценки (joint review process)

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

Процесс разрешения проблем

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

Причинами появления рисков могут выступать следующие:

    1. Нечеткая и/или неполная формулировка требований;
    2. Недостаточная вовлеченность в проект стейкхолдеров;
    3. Неудовлетворительное планирование - отсутствие грамотного управления проектом;
    4. Частое изменение требований, вызванное изменением области применения, целей проекта и другими причинами;
    5. Несовершенство используемой технологии проектирования;
    6. Нехватка знаний или навыков у исполнителей.

Имеется два способа предупреждения рисков:

  1. внесение изменений в требования проекта, устраняющих причину возникновения риска;
  2. разработка технологий, решающих проблему, связанную с появление риска.

В процессе управления проектом руководитель должен время от времени инициировать процесс идентификации рисков в различных частях проекта с целью составления списка рисков, ожидающих своей обработки. Для каждого риска определяются три величины: вероятность осуществления риска; ущерб, наносимый проекту данным риском в случае его осуществления; оценка стоимости устранения риска. Для всех величин используется одна шкала, например 1 – 10.

Процесс документирования и управления конфигурациями

«Управление документацией программного проекта требует значительных организационных усилий, т.к. документация – это сложная система, подверженная постоянным изменениям, которые могут вноситься одновременно множеством людей» (Э. Брауде)

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

ГОСТ Р ИСО/МЭК 9294-93. «Информационная технология. Руководство по управлению документированием программного обеспечения» устанавливает рекомендации по эффективному управлению документированием ПС. Целью стандарта является оказание помощи в определении стратегии документирования ПС; выборе стандартов по документированию; выборе процедур документирования; определении необходимых ресурсов; составлении планов документирования.

Управление документацией подразумевает поддержание ее полны и согласованности (некоторые авторы включают сюда управление конфигурацией).

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

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

  • // требование 4.3
  • // автор
  • // версия
  • // аргументы
  • …листинг метода…

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

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

Для отслеживания частей проекта необходимо определить их границы и выделить элементы конфигурации (Configuration Items - CIs). Элементами конфигурации могут быть классы, реже функции, значимые наборы данных – глобальные таблицы, документация. Учет состояния конфигурации осуществляется посредством регистрации состояния компонентов ПС, подготовку отчетов обо всех реализованных и отвергнутых модификациях версий компонентов ПС. Совокупность отчетов обеспечивает однозначное отражение текущего состояния системы и ее компонентов, а также ведение истории модификаций.
Существуют специальные программные средства для управления конфигурацией (например, Microsoft Visual SourceSafe, Microsoft Visual Studio Team Foundation Server, IBM Rational ClearCase, Subversion и др.).

Обычно системы управления конфигурациями удовлетворяют следующим минимальным требованиям:

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

IEEE разработал стандарт IEEE 828-1990 «План управления конфигурациями программного обеспечения (Software Configuration Management Plan – SCMP)». Заголовок стандарта и пример составление План управления конфигурациями приведен в книге Эрика Брауде.

Рисунок – Нормативные документы вспомогательных процессов ЖЦ

Организационные процессы жизненного цикла

Организационные процессы ЖЦ включают в свой состав: процесс создания инфраструктуры, процесс усовершенствования, процесс обучения, процесс управления.

Рисунок – Структура организационных процессов ЖЦ

Процесс создания инфраструктуры

является процессом установления и обеспечения (сопровождения) инфраструктуры, которая может содержать технические и программные средства, инструментальные средства, методики, стандарты и условия для разработки, эксплуатации или сопровождения. На 1-ом этапе создания инфраструктуры осуществляется выбор CASE-системы поддержки проектирования, выбор языка программирования, СУБД; организацию службы поддержки – системных администраторов, сетевых, администраторов БД, секретарей и т.д.
При решении задачи выбора с использованием литературных источников необходимо проанализировать возможности наиболее распространенных инструментальных систем для того, что построить классификацию, а затем в рамках определенной классификационной группы определить параметры, по которым будет проводиться выбор.
Собственно процедура выбора включает следующие шаги:

    1. Выявляются базовые показатели выбираемой системы, значимые при проектировании заданной АСОИУ с учетом ее особенностей, ограничений, ресурсов и т.д.
    2. Все показатели сводятся в таблицу (см. табл. 5), в которой на основании экспертных оценок каждому показателю назначается весовой коэффициент Vi (например, от 1 до 10), характеризующий значимость данного показателя по сравнению с остальными. Сумма значений всех весовых коэффициентов должна равняться верхней границе весового коэффициента (например, 10).
    3. С использованием данных, полученных из литературных источников и/или от экспертов, по каждому i-ому показателю для каждой j-ой системы определяется степень полезности Ui,j (от 1 – минимальная, до 10 - максимальная). Например, степень полезности система управления конфигурацией, стоимость которой является сравнительно высокой, может равняться 1, тогда как степень полезности свободно распространяемой системы будет равна 10.
    4. Для каждой j-ой сравниваемой системы вычисляется значение оценочной функции по формуле: Fj = V1 x U1,j + V2 x U2,j + …=Σ Vi x Ui,j
    5. На основании значения оценочной функции делается вывод о целесообразности использования той или иной системы в данном проекте при учете выбранных критериев и заданных ограничений. Та система, для которой значение оценочной функции окажется больше, является лучшей с точки зрения выбора из числа сравниваемых альтернатив.

Процесс обучения

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

Процесс усовершенствования

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

Метрики, которыми приходится пользоваться чаще всего следующие:

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

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

    1. Количество дефектов на тысячу строк программного кода, выявленных в течение 12 недель после сдачи проекта.
    2. Отклонения в расписании на каждой фазе: (Фактическая длительность – Плановая длительность) / Плановая длительность.
    3. Отклонения в стоимости: (Фактическая стоимость – Плановая стоимость) / Плановая стоимость.
    4. Общее время проектирования / Общее время программирования (по некоторым оценкам должно составлять не менее 50 %).
    5. Степени появления и обнаружения дефектов на некоторой стадии является одной из простейших метрик.

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

Стадии, на которых были обнаружены дефекты (в данном проекте / норма) Стадии, содержащие дефекты
Формирование требований Техническое задание Эскизный проект
Формирование требований 2/5
Техническое задание 0,5/1,5 3/1
Эскизный проект 0,1/0,3 1/3 2/2

Анализ стадии «Формирование требований» показывает, что степень обнаружения дефектов меньше нормы на всех стадиях проекта. Обнаружено больше дефектов проектирования непосредственно на той фазе, когда они были произведены и на более поздних фазах было обнаружено меньше дефектов. Как правило, это достигается посредством проведения инспектирования.

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

  1. Выявить и определить метрики, которые будут использоваться командой на каждой фазе, включая:
    • время, затраченное на исследование, реализацию и анализ результатов;
    • размер (например, количество строк кода);
    • количество дефектов, обнаруженных в модуле (например, количество строк кода) и источник обнаружения дефекта;
    • оценка качества по шкале от 1 до 10.
  2. Задокументировать полученную информацию в SQAP.
  3. Собирать статистику на каждой фазе.
  4. Назначить разработчиков, ответственных за сбор данных на каждой фазе, например, «ответственный за качество».
  5. Спланировать обзоры полезных в дальнейшем метрических данных. Необходимо заранее определиться с тем, какими могут быть и какими должны быть значения метрик. Полученные данные станут основой для создания базы данных о проектах компании.

Модель зрелости возможностей организации

Процесс совершенствования технологии создания ПО отражается в стратегических планах организации, ее структуре, используемых технологиях, общей социальной культуре и системе управления.
В начале 1990-х годов американский Институт программной инженерии (Software Engineering Institute – SEI университета Карнеги-Меллона (г. Питтсбурге, шт. Пенсильвания, США)) сформировал модель технологической зрелости организаций СММ (Capability [кэпэбилити] Maturity [мэтшэрити] Model). В настоящее время на западе компания-разработчик испытывает значительные трудности в получении заказа, если она не аттестована по CMM.
СММ представляет собой методический материал, определяющий правила формирования системы управления созданием и сопровождением ПО и методы постепенного и непрерывного повышения культуры производства. Назначение СММ – предоставление организациям-разработчикам необходимых инструкций по выбору стратегии повышения качества процессов путем анализа степени их технологической зрелости и факторов, в наибольшей степени влияющих на качество выпускаемой продукции. На каждом уровне СММ устанавливаются требования, при выполнении которых достигается стабилизация наиболее существенных показателей процессов.

Процесс управления

Управление проектом – это достижение баланса между стоимостью, возможностями, качеством и сроками. С процессом управления проектом связано несколько аспектов: управление персоналом, составление плана-графика, оценка стоимости проекта.

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

Известны эмпирические данные по определению оптимального количества членов команды.

Рисунок – Зависимость эффективности команды разработчиков от ее состава

Такая зависимость приводит к необходимости использования иерархической структур управления

Рисунок – Иерархическая структура управления

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

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

Подготовка плана-графика

Существует множество стандартов, описывающих создание и поддержание планов управления программным проектом. Рекомендуется использовать стандарт IEEE 1058.1-1987 план управления программным проектом (Software Project Management Plan – SPMP). В SPMP приводят расписание, определяющее, как и когда должны быть выполнены различные этапы проекта. По окончании выполнения каждого последующего этапа проектирования план-график нуждается в дополнении и корректировке. Наиболее распространенной формой представления плана-графика проекта является диаграмма Ганта.

Рисунок – Примерный вид диаграммы Ганта

Рекомендуется в плане предусматривать буферные периоды, когда не планируется выполнение никаких процессов. План-график в виде диаграммы Ганта, в большинстве случаев, строят с помощью Microsoft Office Project.
Процесс планирования работ по выполнению проекта в частности и управления проектом в целом связан с оценкой стоимости и длительности проекта. Эта информация приводится в разделе 5.4. «Выделение бюджета и ресурсов» SPMP и, кроме того, предварительная оценка стоимости проекта может повлиять на окончательную версию договора между заказчиком и исполнителем, а значит должна быть проведена до подписания ТЗ.

Оценка затрат на создание ПС

Процесс оценки трудоемкости, как правило, начинается одновременно со стартом проекта и продолжается даже на стадии написания программного кода.

Среди наиболее распространенных методов оценки трудоемкости выделяют следующие:

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

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

Процедура оценки трудоемкости разработки ПО состоит из следующих действий:

  1. оценка размера разрабатываемого продукта;
  2. оценка трудоемкости в человеко-месяцах или человеко-часах;
  3. оценка продолжительности проекта в календарных месяцах;
  4. оценка стоимости проекта.

Основными единицами измерения размера ПО являются:

  • количество строк кода (LOC – Lines of Code);
  • функциональные точки (FP – Function Points).

Методология оценивания функционального размера

Методология оценивания функционального размера (FP – Functional Points) заключается в единообразном измерении всех возможностей приложения и выражении размера приложения в виде одного числа. Затем это число можно использовать для оценки числа строк кода, стоимости и сроков проекта.
Для вычисления функционального размера определяют ранг и сложность для каждой информационной характеристики системы. Международная группа пользователей функционального измерения (IFPUG – International Function Point Users Group, www.ifpug.org) опубликовала критерии, по которым следует выделять информационные характеристики, которые делят на пять групп:

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

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

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

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

  • – элементарный процесс, работающий как с вводимыми, так и с выводимыми данными, состоящий из комбинации «запрос-ответ», но не связанный с вычислением производных данных или обновлением ILF. Его результат – данные, возвращаемые из внутренних логических файлов и внешних интерфейсных файлов. Входная часть процесса не модифицирует внутренние логические файлы, а выходная часть не несет данных, вычисляемых приложением (в этом состоит отличие запроса от вывода). Например: вводимые элементы – поле, используемое для поиска, щелчок мыши; выводимые элементы – отображаемые на экране поля.

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

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

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

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

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


Для начала необходимо проанализировать трактовку этапа сопровождения в различных стандартах.

Сопровождение программного обеспечения определяется стандартом IEEE Standard for Software Maintenance (IEEE 1219) как модификация программного продукта после передачи в эксплуатацию для устранения сбоев, улучшения показателей производительности и/или других характеристик (атрибутов) продукта, или адаптации продукта для использования в модифицированном окружении. Интересно, что данный стандарт также касается вопросов подготовки к сопровождению до передачи системы в эксплуатацию, однако, структурно это сделано на уровне соответствующего информационного приложения, включенного в стандарт.

В свою очередь, стандарт жизненного цикла 12207 (IEEE, ISO/IEC, ГОСТ Р ИСО/МЭК) позиционирует сопровождение как один из главных процессов жизненного цикла. Этот стандарт описывает сопровождение как процесс модификации программного продукта в части его кода и документации для решения возникающих проблем при эксплуатации или реализации потребностей в улучшениях тех или иных характеристик продукта. Задача состоит в модификации продукта при условии сохранения его целостности.

Международный стандарт ISO/IEC 14764 (Standard for Software Engineering – Software Maintenance) определяет сопровождение программного обеспечения в тех же терминах, что и стандарт 12207, придавая особое значение работам по подготовке к деятельности по сопровождению до передачи системы в реальную эксплуатацию, например, вопросам планирования регламентов и операций по сопровождению.

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

Ряд источников, в частности, стандарт IEEE 1216, определяют три категории работ по сопровождению: корректировка, адаптация и совершенствование. Такая классификация была обновлена в стандарте ISO/IEC 14764 введением четвертой составляющей.

Таким образом, сегодня говорят о четырех категориях сопровождения:

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

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

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

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

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

Возможность сопровождения или сопровождаемость программной системы определяется, например, глоссарием IEEE (стандарт 610.12-90 Standard Glossary for Software Engineering Terminology, обновление 2002 года) как легкость сопровождения, расширения, адаптации и корректировки для удовлетворения заданных требований. Стандарт ISO/IEC 9126-01 (Software Engineering – Product Quality – Part 1: Quality Model, 2001 г.) рассматривает возможность сопровождения как одну из характеристик качества.

Сопровождаемость должна быть определена до разработки программного средства, т.е подготовлено соответствующее соглашение между заказчиком и поставщиком как часть работы «подготовка» из процесса заказа по (ISO/IEC , #M12291 1200009075 ГОСТ Р ИСО/МЭК) 12207#S . Разработчик формирует план сопровождения, в котором должны быть отражены конкретные методы обеспечения сопровождаемости ПС, соответствующие ресурсы и алгоритм выполнения работ.

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

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

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

На стоимость работ по сопровождению оказывает влияние множество различных факторов. ISO/IEC 14764 определяет, что «существует два наиболее популярных метода оценки стоимости сопровождения: – параметрическая модель и использование опыта». Чаще всего, оба этих подхода комбинируются для повышения точности оценки.

Существуют различные методы внутренней оценки продуктивности персонала сопровождения для сравнения работы различных групп сопровождения. Организация, ведущая сопровождение, должна определить метрики, по которым будут оцениваться соответствующие работы. Стандарты IEEE 1219 и ISO/IEC 9126-01 (Software Engineering – Product Quality – Part 1: Quality Model, 2001 г.) предлагают специализированные метрики, ориентированные именно на вопросы сопровождения и соответствующие программы.

Работы по сопровождению должны быть строго регламентированы и описаны, содержать детальные входы и выходы процессов. Эти процессы рассматриваются в стандартах IEEE 1219 и ISO / IEC 14764.

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

Стандарт ISO/IEC 14764 уточняет положения стандарта жизненного цикла 12207, связанные с процессом сопровождения. Работы по сопровождению, описанные в этом стандарте, аналогичны работам в IEEE 1219, за исключением того, что сгруппированы несколько иначе.

Рассмотрим подробнее выдержки из стандарта ГОСТ Р ИСО/МЭК 14764-2002, содержащего полный аутентичный текст международного стандарта ISO/IEC 14764.

В соответствии с ГОСТ Р ИСО/МЭК 14764-2002, описывающем процесс сопровождения программных средств, подробности процесса сопровождения ПС должны быть документально оформлены, чтобы персонал сопровождения действовал в рамках единого процесса. Система показателей (метрик) качества должна содействовать реализации процесса сопровождения и способствовать усовершенствованию (модернизации) данного ПС.

Сопроводитель должен (5.5.2.1 ГОСТ Р ИСО/МЭК 12207) проанализировать отчет (сообщение) о проблеме или предложение о модификации по их влиянию на организационные вопросы, существующую систему и интерфейсные связи с другими системами.

На основе проведенного анализа сопроводитель должен (5.5.2.3 ГОСТ Р ИСО/МЭК 12207) разработать варианты реализации изменения. До внесения изменений в систему сопроводитель должен (см. 5.5.2.5 ГОСТ Р ИСО/МЭК 12207) получить согласование выбранного варианта изменения в соответствии с договором и подтверждение того, что внесенное изменение удовлетворяет требованиям, установленным в договоре (см. 5.5.4.2 ГОСТ Р ИСО/МЭК 12207). Сопроводитель должен (5.5.2.4 ГОСТ Р ИСО/МЭК 12207) документально оформить: отчет о проблеме или предложение о модификации, результаты их анализа и варианты реализации изменений.

Для соответствующего контроля переноса системы должен быть (5.5.5.2 ГОСТ Р ИСО/МЭК 12207) разработан, документально оформлен и выполнен план переноса объекта. К планируемым работам должны быть привлечены пользователи.

Для деятельности по сопровождению существует ряд уникальных работ и практик, которые необходимо учитывать при организации сопровождения. SWEBOK (Software Engineering Body of Knowledge) приводит следующие примеры такого рода уникальных характеристик.

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

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

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

Анализ влияния: анализ возможных последствий изменений, вносимых в существующую систему.

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

Контракты и обязательства: к ним относятся классическое соглашение об уровне предоставляемого сервиса – Service Level Agreement (SLA), а также другие договорные аспекты, на основании которых, группа/служба/организация по сопровождению выполняет соответствующие работы.

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

Ниже в таблице 1 представлен краткий обзор основных стандартов, применяемых при организации сопровождения информационных систем.

Таблица 1. Стандарты в области сопровождения информационных систем

Стандарт

Название

Описание

На выходе

12207

IEEE, ISO/IEC, ГОСТ Р ИСО/МЭК

Процессы жизненного цикла программных средств

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

1) Выдержки из отчётов пользователей о выявленных дефектах и предложенных корректировках (п. 5.5.2.1 ГОСТ Р ИСО/МЭК 12207 )

2) Предложения по корректировке (п. 5.5.2.3 #M12291 1200009075 ГОСТ Р ИСО/МЭК 12207#S )

3) Извещение пользователям о выпуске новой версии АС (п. 5.5.2.5 #M12291 1200009075 ГОСТ Р ИСО/МЭК 12207#S )

4) План переноса объекта (п. 5.5.5.2 #M12291 1200009075 ГОСТ Р ИСО/МЭК 12207 )

14764

ISO/IEC

ГОСТ Р ИСО МЭК

Сопровождение программных средств

(Standard for Software Engineering – Software Maintenance)

Настоящий стандарт детализирует процесс сопровождения, установленный в 12207 (ISO/IEC , #M12291 1200009075 ГОСТ Р ИСО/МЭК)

9126

ISO/IEC

ГОСТ Р ИСО/МЭК

Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению

Сопроводители должны иметь программу обеспечения качества программного средства, охватывающую шесть характеристик качества , установленных в #M12291 1200009076 ГОСТ Р ИСО/МЭК 9126#S . При сопровождении программного средства должен быть реализован соответствующий процесс для определения, описания, выбора, применения и совершенствования методик оценки (измерения) характеристик данного средства

Характеристики качества:

1) Функциональные возможности

2) Надежность

3) Практичность

4) Эффективность

5) Сопровождаемость

6) Мобильность

ГОСТ 34.603-92

Виды испытаний автоматизированных систем

Стандарт устанавливает виды испытаний АС и общие требования к их проведению.

Испытания АС проводят на стадии «Ввода в действие» по ГОСТ 34.601 с целью проверки соответствия создаваемой АС требованиям технического задания (ТЗ)

Для планирования проведения всех видов испытании разрабатывают документ «Программа и методика испытания».

В программе автономных испытании указывают:

1) перечень (функции, подлежащих испытаниям;

2) описание взаимосвязей объекта испытании с другими частями ПС;

3) условия, порядок и методы проведения испытании и обработки результатов;

4) критерии приемки частей по результатам испытании.

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

IEEE 1219-1998

Стандарт IEEE на сопровождение программного обеспечения

(Standard for Software Maintenance)

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

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

Рассмотрим применение стандартов по сопровождению информационных систем на конкретном примере. Качественное функционирование системы предполагает постоянную адаптацию к изменяющимся бизнес-процессам организации, а также быстрое реагирование на сбои и устранение неполадок. В связи с этим руководством ЗАО «Фирма «СофтИнКом» было принято решение о необходимости заключения договора с разработчиками корпоративной информационной системы (КИС) «Восточный экспресс» на обновление исопровождение системы.

Сопровождение КИС «Восточный экспресс» включает в себя сопровождение нескольких типов (по ГОСТу Р ИСО МЭК 14764-2002). А именно корректирующее сопровождение, которое связано с изменениями, вызванными необходимостью устранения (исправления) фактических ошибок в программном продукте. Корректирующее сопровождение проводят в случае несоответствия программного продукта установленным требованиям. А также адаптивное и полное сопровождение, модернизирующее программный продукт.

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

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

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

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

В таблице 2 приведены основные этапы сопровождения и выход в параграфе сопроводительной документации.

Таблица 2. Этапы процесса сопровождения информационной системы

Входные данные

Этап сопровождения

Выходные данные

Выход в параграфе

Базовая версия АС,

сообщения об ошибках от пользователей

Анализ дефектов и модификаций

Подтверждение (не подтверждение) ошибки или дефекта, пример модификации

Выдержки из отчётов пользователей о выявленных дефектах и предложения по корректировке.

Принятые предложения о модификации, задокументированные в Журнале выявленных дефектов

Реализация модификации

Реализованные и задокументированные изменения

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

Проведённые модификации, задокументированные в журнале подготовленных и утвержденных корректировок

Оценка и принятие результатов сопровождения

Утверждение на удовлетворительное завершение модификации, как определено в контракте на сопровождение

Подготовленное извещение пользователям о выпуске новой версии АС

Миграционный план

Перенос на иную платформу (в иную среду)

Выполненный миграционный план, уведомление пользователей о переносе

Описание миграционного плана. Уведомление пользователя о планах и действиях по перемещению.

В соответствии с 5.5.2.1 ГОСТ Р ИСО/МЭК 12207 сопроводитель должен проанализировать сообщения пользователей о проблеме. Для автоматизации регистрации и учета обращений пользователей КИС «Восточный экспресс» используется система регистрации инцидентов MantisBT. На основе данных, зарегистрированных в системе MantisBT формируется документ «Отчет о дефектах, выявленных пользователями», содержащий следующие поля: номер инцидента, дата создания, категория, суть инцидента, предлагаемое решение.

На основе проведенного анализа сопроводитель должен (5.5.2.3 ГОСТ Р ИСО/МЭК 12207) разработать варианты реализации изменений. Для этого разрабатывается документ «Журнал подготовленных и утвержденных корректировок новой базовой версии КИС», содержащий следующие данные: категория, недочет выявленный сопровождающей организацией, недочет выявленный пользователями КИС, корректировка.

Далее сопроводитель должен (5.5.4.2 ГОСТ Р ИСО/МЭК 12207) получить подтверждение того, что внесенное изменение удовлетворяет требованиям, установленным в договоре. Для этих целей формируется документ «Извещение пользователям о выпуске новой версии КИС» и ожидается подтверждение согласия об установке нового релиза.

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

  • ГОСТ 34.603-92 Виды испытаний автоматизированных систем
  • IEEE 1219-1998 Стандарт IEEE на сопровождение программного обеспечения
  • Сопровождение программного обеспечения (Software Maintenance по SWEBOK) // ‒ Режим доступа:
  • Журнал «Сетевой» №2.2001Статья «Жизненный цикл информационных систем» // ‒ Режим доступа: http://www.setevoi.ru/cgi-bin/text.pl/magazines/2001/2/44
  • Методология и технология разработки информационных систем. Профили открытых информационных систем // ‒ Режим доступа: http://gendocs.ru/v7394/лекции_по_теории_информационных_процессов_и_систем?page=9
    • Количество просмотров публикации: Please wait

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

    Согласно стандарту IEEE-90 под конфигурацией ПО понимается совокупность его функциональных и физических характеристик, установленных в технической документации и реализованных в ПО . Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации по управлению конфигурацией ПО отражены в стандарте ISO / IEC 15288 " Information Technology . Software Life Cycle Process. Configuration Management for Software ".

    Процесс управления конфигурацией включает следующие действия:

    1. подготовительную работу, заключающуюся в планировании управления конфигурацией;
    2. идентификацию конфигурации, устанавливающую правила, с помощью которых однозначно идентифицируются компоненты ПО и их версии. При этом каждому компоненту однозначно соответствует комплект документации;
    3. контроль конфигурации – действие, предназначенное для систематической оценки предлагаемых модификаций ПО и координированной их реализации с учетом эффективности каждой модификации и затрат на ее выполнение;
    4. учет состояния конфигурации, представляющий собой регистрацию состояния компонентов ПО. Обеспечивает подготовку отчетов о реализованных и отвергнутых модификациях версий компонентов ПО. Совокупность отчетов дает однозначное отражение текущего состояния системы и ее компонентов, а также обеспечивает ведение истории модификаций;
    5. оценку конфигурации, заключающуюся в определении функциональной полноты компонентов ПО, а также соответствия их физического состояния текущему техническому описанию;
    6. управление выпуском и поставку, охватывающие изготовление эталонных копий программ и документации, их хранение и поставку пользователям в соответствии с порядком, принятом в организации.

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

    Процесс обеспечения качества включает следующие действия:

    1. подготовительную работу (координацию с другими вспомогательными процессами и планирование самого процесса обеспечения качества ПО с учетом используемых стандартов, методов, процедур и средств);
    2. обеспечение качества продукта, подразумевающего гарантированное полное соответствие ПО и его документации требованиям заказчика, предусмотренным в договоре;
    3. обеспечение качества процесса, предполагающее гарантированное соответствие процессов ЖЦ ПО, методов разработки, среды разработки и квалификации персонала условиям договора, установленным стандартам и процедурам;
    4. обеспечение прочих показателей качества ПО, осуществляемое в соответствии с условиями договора и стандартом качества ISO 9001 .

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

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

    1. непротиворечивость требований, предъявляемых к системе, и степень учета потребностей пользователей;
    2. возможность поставщика выполнить заданные требования;
    3. соответствие выбранных процессов ЖЦ ПО условиям договора;
    4. адекватность стандартов, процедур и среды разработки процессам ЖЦ ПО;
    5. соответствие проектных спецификаций ПО заданным требованиям;
    6. корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, интерфейсов, логики и т.д.;
    7. соответствие кода проектным спецификациям и требованиям;
    8. тестируемость и корректность кода, его соответствие принятым стандартам кодирования;
    9. корректность интеграции компонентов ПО в систему;
    10. адекватность, полнота и непротиворечивость документации.

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

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

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

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

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

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

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

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

    5.4. Организационные процессы ЖЦ ПО

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

    Барышникова Марина Юрьевна
    МГТУ им. Н.Э. Баумана
    Каф. ИУ-7

    Лекция 3

    Жизненный цикл программного
    обеспечения

    Жизненный цикл программного обеспечения

    это период времени, который начинается с
    момента принятия решения о
    необходимости создания программного
    обеспечения и заканчивается в момент
    его полного изъятия из эксплуатации
    (IEEE Std. 610.12 – 19990 Standard Glossary of Software
    Engineering Terminology)

    Основные понятия, участвующие в определении жизненного цикла

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

    Жизненный цикл ПО согласно стандарту ISO/IEC 12207: 1995
    «International Technology – Software Life Cycle Processes»
    (ГОСТ ИСО МЭК 12207-99 Информационные технологии.
    Жизненный цикл программного обеспечения)
    Жизненный цикл
    Организационные
    процессы
    Управление
    проектом
    Создание
    инфраструктуры
    Оценка и улучшение
    жизненного цикла
    Обучение
    Основные
    процессы
    Приобретение
    Вспомогательные
    процессы
    Документирование
    Поставка
    Управление
    конфигурацией
    Разработка
    Обеспечение
    качества
    Эксплуатация
    Верификация
    Сопровождение
    Аттестация
    Совместная
    оценка
    Аудит
    Разрешение
    проблем

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

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

    Процесс разработки

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

    Процесс разработки

    Выбор модели жизненного цикла
    Анализ требований к системе
    Проектирование архитектуры системы
    Анализ программных требований
    Детальное конструирование ПО
    Кодирование и тестирование ПО
    Интеграция ПО
    Квалификационное тестирование ПО
    Интеграция системы
    Квалификационное тестирование системы
    Установка ПО
    Приемка ПО

    10. Анализ требований к системе

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

    11. Анализ требований к ПО

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

    12. Проектирование архитектуры ПО

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

    13. Детальное конструирование ПО (рабочий план разработки ПО)

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

    14. Кодирование и тестирование ПО подразумевает решение следующих задач:

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

    15. Интеграция системы

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

    16. Квалификационное тестирование ПО

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

    17. Установка и приемка ПО

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

    18. Эксплуатация ПО

    Эксплуатация системы выполняется в
    предназначенной для этого среде в
    соответствии с пользовательской
    документацией
    Включает установление
    эксплуатационных стандартов и
    проведение эксплуатационного
    тестирования

    19. Сопровождение ПО (согласно стандарту IEEE – 90)

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

    20. Вспомогательные процессы жизненного цикла ПО

    Документирование
    Управление конфигурацией
    Обеспечение качества
    Верификация
    Аттестация
    Совместная оценка
    Аудит
    Разрешение проблем

    21. Процесс документирования

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

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

    Конфигурация программного обеспечения – это
    совокупность его функциональных и физических
    характеристик, установленных в технической
    документации и реализованных в программах
    Процесс позволяет организовать, систематически
    учитывать и контролировать внесение изменений в
    ПО на всех стадиях жизненного цикла
    Общие принципы и рекомендации по управлению конфигурацией отражены
    в стандарте ISO/IEC CD 12207 – 2:1995 “Information Technology – Software
    Cycle Processes. Part 2. Configuration Management for Software”

    23. Процесс обеспечения качества

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

    24. Верификация

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

    25. Аттестация

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

    26. Организационные процессы жизненного цикла ПО

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

    27. Группы стандартов ЕСПД

    Kод группы
    0
    1
    2
    3
    4
    5
    6
    7
    8
    9
    Наименование группы
    Общие положения
    Основополагающие стандарты
    Правила выполнения документации разработки
    Правила выполнения документации изготовления
    Правила выполнения документации сопровождения
    Правила выполнения эксплуатационной документации
    Правила обращения программной документации
    Резервные группы
    Прочие стандарты
    Обозначение стандарта ЕСПД состоит из:
    числа 19 (присвоенного классу стандартов ЕСПД);
    одной цифры (после точки), обозначающей код классификационной группы стандартов,
    указанный в таблице;
    двузначного числа (после тире), указывающего год регистрации стандарта

    28. Перечень документов ЕСПД

    ГОСТ 19.001-77 ЕСПД. Общие положения
    ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов
    ГОСТ 19.102-77 ЕСПД. Стадии разработки
    ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов
    ГОСТ 19.104-78 ЕСПД. Основные надписи
    ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам
    ГОСТ 19.106-78 ЕСПД. Требования к программным документам, выполненным печатным способом
    ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению
    ГОСТ 19.202-78 ЕСПД. Спецификация. Требования к содержанию и оформлению
    ГОСТ 19.301-79 ЕСПД. Порядок и методика испытаний
    ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению
    ГОСТ 19.402-78 ЕСПД. Описание программы
    ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению
    ГОСТ 19.501-78 ЕСПД. Формуляр. Требования к содержанию и оформлению
    ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению
    ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и
    оформлению
    ГОСТ 19.504-79 ЕСПД. Руководство программиста
    ГОСТ 19.505-79 ЕСПД. Руководство оператора
    ГОСТ 19.506-79 ЕСПД. Описание языка
    ГОСТ 19.508-79 ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и
    оформлению
    ГОСТ 19.604-78 ЕСПД. Правила внесения изменений в программные документы, выполняемые
    печатным способом
    ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и
    правила выполнения
    ГОСТ 19.781-90. Обеспечение систем обработки информации

    29. Преимущества использования стандартов ЕСПД

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

    30. Недостатки стандартов ЕСПД

    ориентация на единственную, «каскадную» модель жизненного
    цикла ПО;
    отсутствие четких рекомендаций по документированию
    характеристик качества программного средства;
    отсутствие системной увязки с другими действующими
    отечественными системами стандартов по жизненному циклу и
    документированию продукции в целом, например, ЕСКД;
    нечетко выраженный подход к документированию ПС как
    товарной продукции;
    отсутствие рекомендаций по самодокументированию ПС,
    например, в виде экранных меню и средств оперативной помощи
    пользователю («хелпов»);
    отсутствие рекомендаций по составу, содержанию и оформлению
    документов на программные средства, согласованных с
    рекомендациями международных и региональных стандартов

    31. Стандарт ГОСТ 34.601-90: стадии и этапы создания автоматизированной системы

    1.
    Формирование требований к АС
    2.
    Разработка концепции АС
    3.
    Изучение объекта
    Проведение необходимых научно-исследовательских работ
    Разработка вариантов концепции АС и выбор варианта концепции АС,
    удовлетворяющего требованиям пользователей
    Оформление отчета о проделанной работе
    Техническое задание
    4.
    Обследование объекта и обоснование необходимости создания АС
    Формирование требований пользователя к АС
    Оформление отчета о выполнении работ и заявки на разработку АС
    Разработка и утверждение технического задания на создание АС
    Эскизный проект
    Разработка предварительных проектных решений по системе и ее частям

    32.

    Стандарт ГОСТ 34.601-90: стадии и этапы
    создания автоматизированной системы
    5.
    Технический проект
    6.
    Рабочая документация
    7.
    Разработка рабочей документации на АС и ее части
    Разработка и адаптация программ
    Ввод в действие
    8.
    Разработка проектных решений по системе и ее частям
    Разработка документации на АС и ее части
    Разработка и оформление документации на поставку комплектующих изделий
    Разработка заданий на проектирование в смежных частях проекта
    Подготовка объекта автоматизации
    Подготовка персонала
    Комплектация АС поставляемыми изделиями (программными и техническими средствами,
    программно-техническими комплексами, информационными изделиями)
    Строительно-монтажные работы
    Пусконаладочные работы
    Проведение предварительных испытаний
    Проведение опытной эксплуатации
    Проведение приемочных испытаний
    Сопровождение АС
    Выполнение работ в соответствии с гарантийными обязательствами
    Послегарантийное обслуживание

    Как фотографировать при свечах (15 полезных советов) Какие я сделал выводы после попытки снять красивый портрет при свечах « Предыдущая запись

    Как фотографировать при свечах (15 полезных советов) Какие я сделал выводы после попытки снять красивый портрет при свечах

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

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

    Свежие записи

    Бухгалтеру о кадрах и налогах. Налоги и взносы. Земельный налог. УСН. ПСН. Охрана труда

    .

    Рубрики
    x

    Хотите получать обновления?

    Подпишитесь, чтобы не пропустить новые публикации