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

Структура ЖЦ ПО в соответствии со стандартом 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). Он охватывает первоначальное обучение и последующее постоянное повышение квалификации персонала.

Цели и задачи методологии проектирования ПО . Основные области проектирования ПО . Этапы создания ПО .

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

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

Программный продукт (Software product) - любой набор компьютерных программ, процедур и связанных с ними документации и данных, получаемых в результате разработки ПП и предназначенных для поставки пользователю [ИСО/МЭК 12207]. Примечание. Продукты включают промежуточные продукты и продукты, предназначенные для пользователей типа разработчиков и персонала сопровождения.

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

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

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

Этапы создания ПО

1. Понять природу и сферу применения предлагаемого продукта.

2. Выбрать процесс разработки и создать план.

3. Собрать требования.

4. Спроектировать и собрать продукт.

5. Выполнить тестирование продукта.

6. Выпустить продукт и обеспечить его сопровождение.

Под жизненным циклом программы будем понимать совокупность этапов:

Анализ предметной области и создание ТЗ (взаимодействия с заказчиком)

Проектирование структуры программы

Кодирование (набор программного кода согласно проектной документации)

Тестирование и отладка

Внедрение программы

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

Утилизация

Понятие жизненного цикла (ЖЦ) программного обеспечения. Определение ЖЦ международным стандартом ISO/IEC 12207:1995. Основные процессы ЖЦ ПО.

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

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

Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995 «Information Technology - Software Life Cycle Processes» (ISO - International Organization for Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

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

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

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

Основные процессы ЖЦ :

Заказ (приобретение);

Действие - инициирование приобретения

Действие – подготовка заявочных предложений

Действие - подготовка и корректировка договора

Действие - надзор за деятельностью поставщика

В процессе приемки подготавливаются и выполняются необходимые тесты. Завершение работ по договору осуществляется в случае удовлетворения всех условий приемки

Поставка;

Инициирование поставки

Планирование

Разработка;

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

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

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

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

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

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

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

Интеграция ПО

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

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

Установка ПО

Приемка ПО

Эксплуатация; охватывает действия и задачи оператора – организации, эксплуатирующей систему и включает действия:

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

планирование действий и работ, выполняемых в процессе эксплуатации, и установку эксплуатационных стандартов;

определение процедур локализации и разрешения проблем, возникающих в процессе эксплуатации.

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

Эксплуатация системы

Поддержка пользователей

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

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

планирование действий и работ, выполняемых в процессе сопровождения;

определение процедур локализации и разрешения проблем, возникающих в процессе сопровождения.

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

Модификация ПО

Проверка и приемка

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

Понятие жизненного цикла (ЖЦ) программного обеспечения. Определение ЖЦ международным стандартом ISO/IEC 12207:1995. Вспомогательные процессы ЖЦ ПО.

См. пункт 2

Вспомогательные процессы ЖЦ :

Документирование ; формализованное описание информации, созданной в течение ЖЦ ПО.

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

подготовительную работу;

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

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

сопровождение

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

подготовительную работу

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

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

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

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

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

Обеспечение качества;

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

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

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

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

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

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

подготовительную работу;

верификацию;

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

непротиворечивость требований к системе и степень учета потребностей пользователей;

возможности поставщика выполнять заданные требования;

соответствие выбранных процессов ЖЦ ПО условиям договора;

адекватность стандартов, процедур и среды разработки процесса ЖЦ ПО;

соответствие проектных спецификаций ПО заданным требованиям;

корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, интерфейсов, логики;

соответствие кода проектным спецификациям и требованиям;

тестируемость и корректность кода, его соответствие принятым стандартам кодирования;

корректность интеграции компонентов ПО в систему;

адекватность, полнота и непротиворечивость документации.

Аттестация ;

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

Совместная оценка (Совместный анализ); для оценки состояния работ по проекту и ПО.

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

Процесс совместной оценки включает действия:

подготовительную работу;

оценку (анализ) управления проектом;

техническую оценку.

Аудит ;

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

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

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

Понятие жизненного цикла (ЖЦ) программного обеспечения. Определение ЖЦ международным стандартом ISO/IEC 12207:1995. Организационные процессы ЖЦ ПО. Взаимосвязь между процессами ЖЦ ПО.

См пункт2

Организационные процессы ЖЦ :

Управление;

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

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

подготовка и определение области управления . Менеджер должен убедиться, что необходимые для управления ресурсы (персонал, оборудование и технология) имеются в его распоряжении в достаточном количестве;

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

составление графиков выполнения работ;

оценку затрат;

выделение требуемых ресурсов;

распределение ответственности;

оценку рисков, связанных с конкретными задачами;

создание инфраструктуры управления.

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

проверка и оценка;

завершение.

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

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

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

предусматривает оценку, измерение, контроль и усовершенствование процессов ЖЦ ПО.

Обучение.

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

Взаимосвязь между процессами ЖЦ ПО

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

договорный аспект;

аспект управления;

аспект эксплуатации;

инженерный аспект;

аспект поддержки.

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

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

Понятие модели и стадии ЖЦ ПО. Характеристика стадий создания ПО .

1) Международный стандарт ISO / IEC 12207: 1995 так определяет модель ЖЦ:

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

2) ГОСТ Р ИСО/ МЭК 12207-99 так определяет модель ЖЦ:

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

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

В состав ЖЦ ПО обычно включают следующие стации:

Формирование требований к ПО.

Проектирование.

Реализация.

Тестирование.

Ввод в действие.

Эксплуатация и сопровождение.

Снятие с эксплуатации.

Понятие модели жизненного цикла программного обеспечения. Водопадная (каскадная) модель жизненного цикла программного обеспечения.

См пункт 5

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

Преимущества применения каскадного способа :

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

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

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

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

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

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

Одним из возможных подходов к разработке прикладного ПО в рамках спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложений, или RAD (Rapid Application Development). RAD предусматривает наличие трех составляющих:

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

короткого, но тщательного проработанного производственного графика (до 3 месяцев);

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

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

Выделяют следующие этапы процесса RAD-разработки :

Бизнес-моделирование . Моделируются информационные потоки между бизнес-функциями.

Моделирование данных . Информационный поток отображается в набор объектов данных.

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

Генерация приложения . Используются языки программирования 4-го поколения, готовые компоненты, для конструирования утилиты автоматизации.

Тестирование и объединение . Применение повторно используемых компонентов уменьшает время тестирования.

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

Недостатки применения RAD :

Для больших проектов требуются значительные людские ресурсы для создания групп.

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

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

Понятие модели жизненного цикла программного обеспечения. V-образная модель жизненного цикла программного обеспечения.

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

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

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

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

Рис. . V-модель жизненного цикла

Ниже дано краткое описание каждой фазы V-образной модели, начиная от планирования проекта и требований вплоть до приемочных испытаний:

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

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

архитектура или проектирование на высшем уровне – определяет, каким образом функции ПО должны применяться при реализации проекта;

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

разработка программного кода – выполняется преобразование алгоритмов, определенных на этапе детализированного проектирования, в готовое программного обеспечения;

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

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

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

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

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

преимуществ:

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

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

в V-образной модели определение требований выполняется перед разработкой проекта системы, а проектирование программного обеспечения - перед разработкой компонентов;

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

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

модель проста в использовании (относительно проекта, для которого она является приемлемом).

недостатки :

с ее помощью непросто справиться с параллельными событиями;

в ней не учтены итерации между фазами;

в модели не предусмотрено внесение требования динамических изменений на разных этапах ЖЦ;

тестирование требований в ЖЦ происходит слишком поздно, вследствие чего невозможно внести изменения, не повлияв при этом на график выполнения проекта;

в модель не входят действия, направленные на анализ рисков.

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

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

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

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

Понятие модели жизненного цикла программного обеспечения. Спиральная модель Боэма жизненного цикла программного обеспечения.

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

Как показано на рис. 3, модель определяет четыре действия, представляемые четырьмя квадрантами спирали:

Планирование - определение целей, вариантов и ограничений.

Анализ риска - анализ вариантов и распознавание/выбор риска.

Конструирование - разработка продукта следующего уровня.

Оценивание - оценка заказчиком текущих результатов конструирования.

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

Международный стандарт IEEE Std 830-1993. Рекомендации по разработке спецификаций требований программного обеспечения.

Одобрено 2 декабря, 1993 Комитетом Стандартов IEEE

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

Ключевые слова: контракт, клиент, прототипирование, спецификация требований программного обеспечения, поставщик, спецификация требований системы

Введение

(Введение не является частью «IEEE Std 830-1993 Рекомендации по разработке спецификаций требований программного обеспечения») Этот документ описывает рекомендуемые подходы к созданию спецификации требований программного обеспечения. Он основан на модели, в которой результатом процесса разработки спецификации требований программного обеспечения является однозначный и полный документ спецификации. Это должно помочь

a) Клиентам программного обеспечения точно описать, что они желают получить

b) Поставщикам программного обеспечения понять точно, чего хочет заказчик

c) Индивидуумам выполнить следующие цели:

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

2) Определить формат и содержание собственных спецификаций требований программного обеспечения

3) Включить дополнительные пункты требований, такие как спецификация требований контроля качества (quality checklist) или спецификация требований к написанию руководства (writer"s handbook).

Хорошие спецификации должны обеспечить клиентам, поставщикам и другим индивидуумам несколько определенных преимуществ, таких как:

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

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

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

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

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

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

1 Краткий обзор (Overview)

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

Пункт 1 объясняет возможности этого стандарта.

Пункт 3 содержит используемые определения.

Пункт 4 обеспечивает информационную основу для разработки СТПО.

Пункт 5 обсуждает каждую из существенных частей СТПО.

Стандарт также имеет приложения, в которых приводятся альтернативные шаблоны форматов СТПО.

1.1 Возможности (Scope)

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

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

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

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

Стандарт не определяет никаких специальных методов, терминологии (nomenclature) или инструментов для подготовки СТПО.

2 Ссылки (References)

ASTM 1340-90, Standard Guide for Rapid Prototyping of Computerized Systems

IEEE Std 610.12- 1990, IEEE Standard Glossary of Software Engineering Terminology (ANSI).

IEEE Std 730-1989, IEEE Standard for Software Quality Assurance Plans (ANSI).

IEEE Std 828-1990, IEEE Standard for Software Configuration Management Plans (ANSI).

IEEE Std 982.1-1988, IEEE Standard Dictionary of Measures to Produce Reliable Software (ANSI).

IEEE Std 982.2-1988, IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software (ANSI).

IEEE Std 983-1986, IEEE Guide to Software Quality Assurance Planning.

IEEE Std 1002-1987, IEEE Standard Taxonomy for Software Engineering Standards (ANSI).

IEEE Std 1012-1986, IEEE Standard for Software Verification and Validation Plans (ANSI).

IEEE Std 1016-1987, IEEE Recommended Practice for Software Design Descriptions (ANSI).

IEEE Std 1028- 1988, IEEE Standard for Software Reviews and Audits (ANSI).

IEEE Std 1042-1987, IEEE Guide to Software Configuration Management (ANSI).

IEEE Std 1058.1-1987, IEEE Standard for Project Management Plans (ANSI).

IEEE Std 1074-1991, IEEE Standard for Developing Software Life Cycle Processes (ANSI).

3 Определения (Definitions)

Вообще определения терминов, используемых в этом документе соответствуют определениям, сформулированным в IEEE Std 610.12-1990.5. Ниже даны определения ключевых терминов, поскольку они используются в этом документе.

3.1 Контракт (contract).

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

3.2 Клиент (customer).

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

3.3 Поставщик (supplier).

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

3.4 Пользователь (user).

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

4 Соображения по созданию хороших СТПО (Considerations for producing a good SRS)

Этот пункт обеспечивает информационную основу для разработки СТПО. Включает следующее:

a) Сущность СТПО

b) Контекст СТПО

c) Характеристики хороших СТПО

d) Совместная подготовка СТПО

e) Процесс изменения СТПО

f) Прототипирование

g) Включение проекта в СТПО

h) Включение требований проектирования в СТПО

4.1 Сущность СТПО (Nature of the SRS)

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

Основные вопросы, которые должен рассматривать разработчик СТПО:

a) Функциональные возможности. Что программа должна делать?

b) Внешние интерфейсы. Как программное обеспечение взаимодействует с людьми, системным аппаратным обеспечением, другим оборудованием и другим программным обеспечением?

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

d) Характеристики (Attributes). Какова переносимость, корректность, ремонтопригодность, безопасность, и т.д.?

e) Ограничения проекта, наложенные на реализацию. Требования любых существующих стандартов, язык выполнения, политика обеспечения целостности базы данных, ограничения на ресурсы, операционная среда (ы) исполнения и т.д.?

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

4.2 Контекст СТПО (Environment of the SRS)

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

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

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

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

b) Не должен описывать никакого проектирования или деталей выполнения. Они должны быть описаны в стадии разработки проекта.

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

4.3 Характеристики хороших СТПО (Characteristics of a good SRS)

СТПО должны иметь следующие характеристики

d) Правильный

e) Однозначный

g) Последовательный

h) Оцениваемы по важности и/или стабильности

i) Поддающийся проверке

j) Поддающийся изменению

k) Трассируемый

4.3.1 Правильный (Correct)

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

4.3.2 Непротиворечивый (Unambiguous)

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

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

4.3.2.1 Сложности естественного языка (Natural language pitfalls)

Требования часто написаны на естественном языке (например, английском языке). Естественный язык неотъемлемо неоднозначен. Для того чтобы определить неоднозначное использование естественного языка, СТПО должны быть рассмотрены независимой стороной, с тем, чтобы выявленные неоднозначности были исправлены.

4.3.2.2 Языки спецификаций требований (Requirements specification languages)

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

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

4.3.2.3 Инструменты представления (Representation tools).

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

Степень полезности таких инструментов и методов при создании СТПО зависит от размера и сложности программы. Здесь не делается попыток описать или рекомендовать какой-либо конкретный инструмент.

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

4.3.3 Полный (Complete)

СТПО полны тогда, и только тогда, когда они включают следующие элементы:

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

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

4.3.3.1 Использование фразы “будет определено” (Use of TBDs)

Любые СТПО, которые используют фразу “будет определено” (TBD) – не являются полными, однако, они иногда необходимы и должны сопровождаться следующим

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

b) Описанием того, что должно быть выполнено, чтобы устранить фразу “будет определено”, кто ответственен за устранение, когда должно быть устранено.

4.3.4 Целостный (Consistent)

Целостность относится к внутренней целостности. Если СТПО противоречат документам более высокого уровня, типа спецификации требований системы, то это неправильно (см. 4.3.1).

4.3.4.1 Внутренняя целостность (Internal consistency)

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

a) Указанные характеристики объектов могут находиться в противоречии. Например,

1) Выходной отчет может быть описан в одном требовании как табличный, а в другом как - текстовый.

2) Одно требование может установить, что все индикаторы должны быть зеленого цвета, а другое требование, что голубого.

b) Может иметься логический или временной конфликт между двумя указанными действиями. Например.

1) Одно требование может определить, что программа сложит две входных величины, другое - умножит их.

2) Одно требование устанавливает, что событие “A” должно всегда следовать за событием “B”, в то время как, другое требование устанавливает, что события “А” и “B” происходят одновременно.

3) Два или более требований могут описывать один и тот же объект, но использовать различные термины для этого объекта. Например, запрос программы на ввод пользователя может называться "prompt" в одном требовании и "cue" в другом. Использование стандартных терминологии и определений улучшает целостность.

4.3.5 Оцениваемый по важности и/или стабильности (Ranked for importance and/or stability)

СТПО оценивается по важности и/или стабильности, если каждое требование имеет идентификатор, который определяет важность и/или стабильность данного требования.

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

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

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

b. Разработчикам принимать правильные проектные решения и уделять необходимое внимание различным частям программного продукта.

4.3.5.1 Степень стабильности (Degree of stability)

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

4.3.5.2 Степень потребности (Degree of necessity)

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

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

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

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

4.3.6 Проверяемость (Verifiable)

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

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

Пример проверяемого утверждения

Завершение программы должно быть произведено в пределах 20 с в 60 % случаев и в пределах 30 с в l00 % случаев

Это утверждение проверяемо, потому что использует конкретные термины, измеримые количественно.

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

4.3.7 Изменяемость (Modifiable)

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

a) Иметь последовательную и удобную в работе структуру с оглавлением, индексом, и явными взаимными ссылками

b) Не быть избыточным; то есть одно и то же требование не должно встречаться больше чем одном месте в СТПО

c) Выражать каждое требование предпочтительнее отдельно, чем смешанным с другими требованиями

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

4.3.8 Трассируемость (Traceable)

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

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

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

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

4.4 Совместная подготовка СТПО (Joint preparation of the SRS)

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

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

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

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

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

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

4.5 Развитие СТПО (SRS evolution)

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

В этом процессе необходимо учитывать два следующих главных момента:

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

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

1) Обеспечить точный и полный контроль изменений.

2) Разрешить просмотр текущих и измененных частей СТПО

4.6 Прототипирование (Prototyping)

Прототипирование часто используется на этапе разработки требований проекта. Имеется много инструментов, которые позволяют из шаблона, путем задания параметров легко и быстро получать прототипы системы. См. также ASTM Std 1340-90.

Прототипы полезны по трем причинам:

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

b) Опытный образец показывает непредвиденные аспекты поведения систем. Таким образом, он не только отвечает на возникшие вопросы, но и задает новые. Это помогает достичь завершения разработки СТПО.

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

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

4.7 Включение проекта в СТПО (Embedding design in the SRS)

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

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

a) Разделение программного обеспечения на модули

b) Распределение функций по модулям

c) Описание потока информации или взаимодействия между модулями

d) Выбор структур данных

4.7.1 Необходимые требования проекта (Necessary design requirements)

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

a) Держать некоторые функции в отдельных модулях

b) Разрешить ограниченную связь между некоторыми областями программы

c) Проверить целостность данных для критических переменных

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

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

4.8 Включение требований проектирования в СТПО (Embedding project requirements in the SRS)

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

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

a) Стоимость

b) План-графики поставки

c) Отчетные мероприятия

d) Методы разработки программного обеспечения

e) Гарантии качества

f) Испытания и критерии проверки

g) Процедуры приемки

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

5 Разделы СТПО (The parts of an SRS)

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

1. Введение

1.2 Границы применения

1.3 Термины, акронимы, сокращения

1.5 Краткий обзор

2. Общее описание

2.1 Перспективы изделия

2.2 Функции изделия

2.3 Характеристики пользователя

2.4 Ограничения

2.5 Предположения и зависимости

3. Детальные требования (См. 5.3.1-5.3.8 для объяснений возможных детальных требований. См. также приложение A для нескольких различных структур этого раздела СТПО)

Приложения

Индексы

Рисунок 1 Образец схемы СТПО

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

5.1 Введение (Introduction) (Раздел 1 СТПО)

Введение СТПО должно обеспечить краткий обзор всего СТПО. Оно должно содержать следующие подразделы:

b) Границы применения

c) Определения, акронимы (аббревиатуры) и сокращения

d) Краткий обзор

5.1.1 Цели (Purpose) (1.1 из СТПО)

Этот подраздел должен выполнить следующее:

a) Очертить цель детальных СТПО

b) Определить аудиторию, для которой предназначено СТПО

5.1.2 Границы применения (Scope) (1.2 из СТПО)

Этот подраздел должен

c) Идентифицировать изделие (я) программного обеспечения, которое будет произведено, наименование (например, “Серверная СУБД”, “Генератор Отчетов” и т.д.)

d) Объяснить, что изделие (я) программного обеспечения будет, и, если необходимо, не будет делать

e) Описать применения определяемого программного обеспечения, включая важные преимущества, объекты и цели

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

5.1.3 Термины, акронимы (аббревиатуры), сокращения (Definitions, acronyms, and abbreviations) (1.3 из СТПО)

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

Этот подраздел должен

a) Обеспечить полный список всех документов, упомянутых в каком либо месте в СТПО

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

Эта информация может быть обеспечена посредством ссылок на одно или большее количество приложений к СТПО или посредством ссылок на другие документы.

5.1.5 Краткий обзор (Overview) (1.5 из СТПО)

Этот подраздел должен

a) Описать, что содержит остальная часть СТПО

b) Объяснить, как СТПО структурировано

5.2 Общее описание (Overall description) (Раздел 2 из СТПО

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

Этот раздел обычно состоит из шести следующих подразделов:

a) Описание изделия

b) Функции изделия

c) Характеристики пользователей

d) Ограничения

e) Предположения и зависимости

f) Поднаборы требований

5.2.1 Описание изделия (Product perspective) (2.1 из СПТО)

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

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

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

a) Интерфейсы системы

b) Интерфейсы пользователя

c) Интерфейсы аппаратных средств ЭВМ

d) Интерфейсы программного обеспечения

e) Интерфейсы коммуникаций

f) Ограничения памяти

g) Функционирование (Operations)

h) Требования настройки рабочих мест

5.2.1.1 Интерфейсы системы (System interfaces)

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

5.2.1.2 Интерфейсы пользователя (User interfaces)

Необходимо определить:

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

b) Все аспекты оптимизации интерфейса между продуктом программного обеспечения и пользователями, которые этот продукт используют. Это может просто включать список того, что система должна и чего она не должна делать с точки зрения пользователя. Одним из примеров является требование выбора длинных или коротких сообщений об ошибках. Аналогично другим требованиям эти требования должны быть проверяемыми, например, " машинистка 4-го разряда может выполнять функцию X за Z минут после 1 часа обучения" предпочтительнее, чем "машинистка может выполнять функцию X" (Это может также быть определено в системных характеристиках программного обеспечения под разделом, озаглавленным “Удобство использования” (Ease of Use)).

5.2.1.3 Интерфейсы аппаратных средств ЭВМ (Hardware Interfaces)

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

5.2.1.4 Интерфейсы программного обеспечения (Software Interfaces)

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

a) Наименование

b) Мнемоническое наименование

c) Номер спецификации

d) Номер версии

e) Источник Для каждого интерфейса необходимо обеспечить следующее:

a) Обсуждение назначения взаимодействующих программ по отношению к данному продукту.

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

5.2.1.5 Интерфейсы коммуникаций (Communications interfaces)

Здесь необходимо определить различные интерфейсы средств связи типа протоколов локальной сети и т.д.

5.2.1.6 Ограничения памяти (Memory constraints)

Здесь необходимо определить любые применимые характеристики и их значения для оперативной и постоянной памяти.

5.2.1.7 Действия (Operations)

Здесь необходимо определить нормальные и специальные действия, необходимые пользователям, типа

a) Различные способы действий в организации пользователя; например операции, инициируемые пользователем

b) Периоды диалоговых действий и периоды оставленных без отклика действий

c) Функции поддержки обработки данных

d) Действия резервного копирования и восстановления

ПРИМЕЧАНИЕ – этот пункт иногда определяется как часть раздела интерфейсов пользователя.

5.2.1.8 Требования настройки рабочих мест (Site adaptation requirements)

Здесь необходимо

a) Определить требования для любых данных или командных строк (initialization sequences), которые определяются для данного рабочего места, задачи, или режима эксплуатации, например, разрешение экрана (grid values), пределы безопасности (safety limits) и т.д.

b) Определите характеристики рабочего места или решаемых задач, которые должны быть изменены, чтобы настроить программное обеспечение на специальную конфигурацию.

5.2.2 Функции изделия (Product functions) (2.2 из СТПО)

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

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

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

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

5.2.3 Характеристики пользователей (User characteristics) (2.3 из СТПО)

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

Внешние стандарты

IEEE Std 830-1993

сформулировать детальные требования, здесь скорее необходимо объяснить причины, по которым эти требования появятся позже в разделе 3 СТПО.

5.2.4 Ограничения (Constraints) (2.4 из СТПО)

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

a) Регулирующую политику

b) Ограничения аппаратных средств ЭВМ (например, требования по времени выбора)

c) Интерфейсы с другими приложениями

d) Параллельную работу

e) Функции протоколирования

f) Функции управления

g) Требования к языкам высокого уровня

h) Протоколы интерфейсов синхронизации сигналов (например, XON-XOFF, ACK-NACK)

i) Требования надежности

j) Критичность приложения

k) Соображения безопасности и секретности

5.2.5 Предположения и зависимости (Assumptions and dependencies) (2.5 из СТПО)

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

5.2.6 Распределение требований (Apportioning of requirements) (2.6 из СТПО)

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

5.3 Детальные требования (Specific requirements) (Секция 3 из СТПО)

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

Поскольку это - часто самая большая и наиболее важная часть СТПО, то необходимо применять следующие принципы:

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

b) Детальные требования должны иметь перекрестные ссылки к более ранним документам, к которым имеют отношение.

c) Все требования должны быть уникально идентифицированы.

d) Для повышения удобочитаемости необходимо особое внимание уделить структурированию требований.

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

5.3.1 Внешние интерфейсы (External interfaces)

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

a) Наименование пункта

b) Описание цели

c) Источник входных или назначение выходных данных

d) Диапазон допустимых значений, точность и/или допустимые отклонения

e) Единицы измерения

f) Временные характеристики

g) Отношения к другим входам / выходам

h) Форматы / организация экрана

i) Форматы / организация окна

j) Форматы данных

k) Форматы команд

l) Конечные сообщения

5.3.2 Функции(Functions)

Функциональные требования определяют фундаментальные действия, которые должны иметь место в программном обеспечении при получении и обработке входных данных и при формировании выходных данных. Они обычно включаются в список, как "должна" в начале определения функционального требования. “Система должна... “

Описание включает:

a) Проверку допустимости данных на входах

b) Точную последовательность действий

c) Действия при возникновении исключительных ситуаций, включая

1) Переполнение

2) Средства связи (Communication facilities)

3) Обработку ошибок и восстановление

d) Влияние параметров

e) Отношения входных данных к выходным данным, включая

1) Последовательности Входных данных / выходных данных

2) Формулы для преобразования входных данных в выходные

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

5.3.3 Требования исполнения (Performance requirements)

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

a) Число терминалов, которое должны быть поддержаны

b) Количество одновременно работающих пользователей, которое должно быть поддержано

c) Количество и тип информации, которая должна обрабатываться

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

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

Все эти требования должны быть заявлены в терминах единиц измерения.

Например, 95 % сделок должны быть обработаны меньше чем 1 s предпочтительнее чем, оператор не должен ждать, чтобы завершить сделку.

ПРИМЕЧАНИЕ - численные ограничения, применяемые к одной специфической функции обычно определяются как часть подпараграфа описания работы этой функции.

5.3.4 Требования логики базы данных (Logical database requirements)

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

d) Типы информации, используемые различными функциями

e) Частота использования

f) Способы доступа.

g) Сущности данных и их отношения

h) Ограничения целостности

i) Требования хранения данных

5.3.5 Ограничения проекта (Design constraints)

Здесь определяются ограничения разработки, которые могут накладываться другими стандартами, ограничениями аппаратных средств ЭВМ и т.д.

5.3.5.1 Соглашение о стандартах (Standards compliance)

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

a) Формат сообщений

b) Именование данных

c) Отчетные процедуры (Accounting procedures)

d) Протоколирование (Audit tracing)

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

5.3.6 Характеристики программного обеспечения системы (Software system attributes)

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

5.3.6.1 Надежность (Reliability)

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

5.3.6.2 Эксплуатационная готовность (Availability)

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

5.3.6.3 Безопасность (Security)

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

a) Использовать некоторые методы шифрования

c) Назначать некоторые функции в различные модули

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

e) Проверять целостность данных для критических переменных

5.3.6.4 Ремонтопригодность (Maintainability)

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

5.3.6.5 Переносимость (Portability)

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

f) Процент компонентов с машинозависимым кодом

g) Процент кода, который является машинозависимым

h) Использование проверенного переносимого языка

i) Использование конкретного компилятора или поднабора языков

j) Использование конкретной операционной системы

5.3.7 Структурирование детальных требований (Organizing the specific requirements)

Для нетривиальных систем детальные требования могут быть обширными. По этой причине, рекомендуется обеспечивать такое их структурирование, которое делает их оптимальными для понимания. Не существует оптимальной структуры для всех систем. Различные способы структурирования требований для различных классов систем предоставлены в разделе 3 СТПО. Некоторые структуры описаны в следующих подразделах.

5.3.7.1 Режим системы (System mode)

Некоторые системы ведут себя весьма различно в зависимости от режима работы. Например, система управления может иметь различные наборы функций в зависимости от использования: обучение, нормальная или аварийная ситуация. При организации деления на режимы используйте схемы, показанные в разделах 1 или 2 приложения A. Выбор определяется тем, зависят ли интерфейсы и выполнение программы от режима работы.

5.3.7.2 Классы пользователей (User class)

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

5.3.7.3 Объекты (Objects)

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

показанную в разделе 4 приложения A. Обратите внимание, что наборы объектов могут разделяться по атрибутам и услугам. Они сгруппированы вместе как классы.

5.3.7.4 Особенности (Feature)

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

5.3.7.5 Воздействие (Stimulus)

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

5.3.7.6 Реакция (Response)

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

5.3.7.7 Функциональные иерархии (Functional hierarchy)

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

5.3.8 Дополнительные комментарии (Additional comments)

Когда определено новое требование, оно может соответствовать нескольким способам структурирования, описанным в 5.3.7.7. В таких случаях, структурируйте детальные требования во множественные иерархии, приспособленные к специальным потребностям специфицируемой системы. Например, см. 8 в приложении A для организации, объединяющей класс пользователя и особенность. Любые дополнительные требования могут быть помещены в отдельный раздел в конце СТПО.

Существует большое количество доступных описаний, методов и автоматизированных инструментов поддержки, помогающих в документировании требований. Главным образом, их ценность - это функция структурирования. Например, при структурировании по режимам (when organizing by mode), могут быть полезными конечные автоматы или диаграммы состояний; при структурировании по объектам, может быть полезным объектно-ориентированный анализ; при структурировании по особенностям могут быть полезными последовательности «воздействие – реакция»; при

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

В любой из схем, приведенных в 1-8, разделы, которые именуются как "Функциональные Требования", могут быть написаны на родном языке (например, Английский язык), в псевдокодах, на языке описания систем, или в виде четырех подразделов: Введение, Входы, Обработка (Processing), Выходы.

5.4 Информационная поддержка (Supporting information)

Информационная поддержка облегчает использование СТПО. Она включает

b) Индексы

c) Приложения

5.5 Приложения (Appendixes)

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

a) Образцы форматов ввод - вывода, описания анализа стоимости обучения, или результатов обследования пользователей

b) Сопровождающая или подготовительная информация, которая может помочь читателям СТПО

c) Описание проблем, которые будут решены с помощью программного обеспечения

d) Специальные упаковочные инструкции (Special packaging instructions) для кода и информационные средства, необходимые для обеспечения безопасности, экспорта, начальной загрузку или другие требования

Если имеются приложения, СТПО должны явно объявить, рассматриваются или нет приложения как часть требований.

6 Приложение A (Информативно)

6.1 Шаблон раздела 3 СТПО организованный по режимам: Версия 1
3 Детальные требования
3.1 Требования на внешние интерфейсы



3.1.4 Интерфейсы связи

3.2.1 Режим 1

3.2.2 Режим 2
3. 2. m. Режим m
3. 2. m.1 Функциональное требование м.
3. 2. m.n Функциональное требование m.n
3.3 Требования исполнения
3.4 Ограничения проекта

3.6 Другие требования
6.2 Шаблон раздела 3 СТПО организованный по режимам: Версия 2
3. Детальные требования
3.1. Функциональные требования
3.1.1 Режим 1
3.1.1.1 Внешние интерфейсы
3. 1.1.1.1 Интерфейсы пользователя
3. 1.1.1.2 Интерфейсы аппаратных средств ЭВМ
3. 1.1.1.3 Интерфейсы программного обеспечения
3. 1.1.1.4 Интерфейсы связи
3.1.1.2 Функциональные требования
3.1.1.2.1 Функциональных требование 1
3.1.1.2.n Функциональное требование n
3.1.1.3 Требования исполнения
3.1.2 Режим 2
3.1.m. Режим m.
3.2 Ограничения проекта
3.3 Характеристики программного обеспечения системы
3.4 Другие требования
6.3 Шаблон раздела 3 СТПО организованный по классам пользователей
3 Детальные требования

3.1.1 Интерфейсы пользователя
3.1.2 Интерфейсы аппаратных средств ЭВМ
3.1.3 Интерфейсы программного обеспечения
3.1.4 Интерфейсы связи
3.2 Функциональные требования
3.2.1 Класс пользователя 1
3.2.1.1 Функциональное требование 1.1
3.2.1.n Функциональное требование 1. n
3.2.2 Класс пользователя 2
3.2.m. Класс пользователя m.


3.3 Требования исполнения
3.4 Ограничения проекта
3.5 Характеристики программного обеспечения системы
3.6 Другие требования
6.4 Шаблон раздела 3 СТПО организованный по объектам
3 Детальные требования
3.1 Требования внешних интерфейсов
3.1.1 Интерфейсы пользователя
3.1.2 Интерфейсы аппаратных средств ЭВМ
3.1.3 Интерфейсы программного обеспечения
3.1.4 Интерфейсы связи
3.2 Классы / объекты
3.2.1 Класс / объект 1
3.2.1.1 Атрибуты (собственные или унаследованные)
3.2.1.1.1 Атрибут 1
3.2.1.1.n Атрибут n
3.2.1.2 Функции (методы. Собственные или унаследованные)
3.2.1.2.1 Функциональное требование 1.
3.2.1.2.m Функциональное требование m
3.2.1.3 Сообщения (полученные или отправленные)
3.2.2 Класс / объект 2
3.2.p Класс / объект p
3.3 Требования исполнения
3.4 Ограничения проекта
3.5 Характеристики программного обеспечения системы
3.6 Другие требования
6.5 Шаблон раздела 3 СТПО организованный по особенностям
3 Детальные требования
3.1 Требования внешних интерфейсов
3.1.1 Интерфейсы пользователя
3.1.2 Интерфейсы аппаратных средств ЭВМ
3.1.3 Интерфейсы программного обеспечения
3.1.4 Интерфейсы связи
3.2 Особенности системы
3.2.1 Особенность системы 1
3.2.1.1 Введение / цель
3.2.1.2 Последовательность воздействие / реакция
3.2.1.3 Связанные функциональные требования
3.2.1.3.1 Функциональное требование 1
3.2.1.2.n Функциональное требование n
3.2.2 Особенность системы 2
3.2.m Особенность системы m.
3.3 Требования исполнения
3.4 Ограничения проекта
3.5 Характеристики программного обеспечения системы
3.6 Другие требования
6.6 Шаблон раздела 3 СТПО организованный по воздействиям
3 Детальные требования
3.1 Требования внешних интерфейсов
3.1.1 Интерфейсы пользователя
3.1.2 Интерфейсы аппаратных средств ЭВМ
3.1.3 Интерфейсы программного обеспечения
3.1.4 Интерфейсы связи
3.2 Функциональные требования
3.2.1 Воздействие 1
3.2.1.1 Функциональное требование 1.1
3.2.1.n Функциональное требование l.n
3.2.2 Воздействие 2
3.2.m Воздействие m
3.2.m.1 Функциональное требование m.1
3.2.m.n Функциональное требование m.n
3.3 Требования исполнения
3.4 Ограничения проекта
3.5 Характеристики программного обеспечения системы
3.6 Другие требования
6.7 Шаблон раздела 3 СТПО организованный по функциональной иерархией
3 Детальные требования
3.1 Требования внешних интерфейсов
3.1.1 Интерфейсы пользователя
3.1.2 Интерфейсы аппаратных средств ЭВМ
3.1.3 Интерфейсы программного обеспечения
3.1.4 Интерфейсы связи
3.2 Функциональные требования
3.2.1 Информационные потоки
3.2.1.1 Диаграмма потока данных 1
3.2.1.1.1 Сущности данных
3.2.1.1.2 Подходящие процессы (Pertinent processes)
3.2.1.1.3 Топология (Topology)
3.2.1.2 Диаграмма потока данных 2
3.2.1.2.1 Сущности данных
3.2.1.2.2 Подхордящие процессы (Pertinent processes)
3.2.1.2.3 Топология (Topology)
3.2.1.n Диаграмма потока данных n
3.2.1.n.1 Сущности данных
3.2.1.n.2 Подходящие процессы (Pertinent processes)
3.2.1.n.3 Топология (Topology)
3.2.2 Описание процессов
3.2.2.1 Процесс 1
3.2.2.1.1 Сущности данных на входе
3.2.2.1.2 Алгоритм или формула процесса
3.2.2.1.3 Сущности данных, оказывающие воздействие (Affected data entities)
3.2.2.2 Процесс 2
3.2.2.2.1 Сущности данных на входе
3.2.2.2.2 Алгоритм или формула процесса
3.2.2.2.3 Сущности данных, оказывающие воздействие (Affected data entities)
3.2.2.m Процесс m
3.2.2.m.1 Сущности данных на входе
3.2.2.m.2 Алгоритм или формула процесса
3.2.2.m.3 Сущности данных, оказывающие воздействие (Affected data entities)
3.2.3 Спецификации структур данных
3.2.3.1 Структура 1
3.2.3.1.1 Тип записи
3.2.3.1.2 Элементарные поля
3.2.3.2 Структура 2
3.2.3.2.1 Тип записи
3.2.3.2.2 Элементарные поля
3.2.3.p Структура p
3.2.4 Словарь данных
3.2.4.1 Элемент данных 1
3.2.4.1.1 Наименование
3.2.4.1.2 Представление
3.2.4.1.3 Единицы / формат
3.2.4.1.4 Точность представления / точность округления (Precision/Accuracy)
3.2.4.1.5 Диапазон значений
3.2.4.2 Элемент данных 2
3.2.4.2.1 Наименование
3.2.4.2.2 Представление
3.2.4.2.3 Единицы / формат
3.2.4.2.4 Точность представления / точность окрудления (Precision/Accuracy)
3.2.4.2.5 Диапазон значений
3.2.4.1.q Элемент данных q
3.2.4.q.1 Наименование
3.2.4.q.2 Представление
3.2.4.q.3 Единицы измерения / формат
3.2.4.q.4 Точность представления / точность округления (Precision/Accuracy)
3.2.4.q.5 Диапазон
3.3 Требования исполнения
3.4 Ограничения проекта
3.5 Характеристики программного обеспечения системы
3.6 Другие требования
6.8 Шаблон раздела 3 СТПО показывающий множественную организацию
3 Детальные требования
3.1 Требования внешних интерфейсов
3.1.1 Интерфейсы пользователя
3.1.2 Интерфейсы аппаратных средств ЭВМ
3.1.3 Интерфейсы программного обеспечения
3.1.4 Интерфейсы связи
3.2 Функциональные требования
3.2.1 Класс пользователей 1
3.2.1.1 Особенность 1.1
3.2.1.1.1 Введение / цель
3.2.1.1.2 Последовательность воздействие / реакция
3.2.1.1.3 Связанные функциональные требования
3.2.1.2 Особенность 1.2
3.2.1.2.1 Введение / цель
3.2.1.2.2 последовательность Стимула / ответа
3.2.1.2.3 Связанные функциональные требования
3.2.1.m. Особенность 1.m
3.2.1.m.1 Введение / цель.
3.2.1.m.2 Последовательность воздействие / реакция
3.2.1.m.3 Связанные функциональные требования
3.2.2 Класс пользователей 2
3.2.n Класс пользователей n
3.3 Требования исполнения
3.4 Ограничения проекта
3.5 Характеристики программного обеспечения системы
3.6 Другие требования

• Вконтакте

Сопровождение всегда признавалось одним из основных этапов жизненного цикла программного обеспечения. Уже к середине 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

Барышникова Марина Юрьевна
МГТУ им. Н.Э. Баумана
Каф. ИУ-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.
Разработка проектных решений по системе и ее частям
Разработка документации на АС и ее части
Разработка и оформление документации на поставку комплектующих изделий
Разработка заданий на проектирование в смежных частях проекта
Подготовка объекта автоматизации
Подготовка персонала
Комплектация АС поставляемыми изделиями (программными и техническими средствами,
программно-техническими комплексами, информационными изделиями)
Строительно-монтажные работы
Пусконаладочные работы
Проведение предварительных испытаний
Проведение опытной эксплуатации
Проведение приемочных испытаний
Сопровождение АС
Выполнение работ в соответствии с гарантийными обязательствами
Послегарантийное обслуживание