Учебное пособие 1295

• Возможности.

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

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

• Деятельности.

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

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

Изменения в требованиях анализируются и включаются

впроект.

•Измерение.

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

• Проверки.

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

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

- Интегрированная модель зрелости возможностей

CMMI (Capability Maturity Model Integration).

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

51

-Созданы два несколько отличающихся изложения модели - непрерывное и поэтапное. Первое предназначено для облегчения миграции от поддержки американского отраслевого стандарта EIA/AIS 713 и постепенного усовершенствования процессов за счет внедрения различных практик. Второе предназначено для облегчения миграции от поддержки СММ и поуровневого рассмотрения вводимых практик.

-Элементы модели получили четкие пометки о том, являются ли они обязательными (required), рекомендуемыми (expected) или информативными (informative).

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

-Некоторые уровни зрелости получили другие названия. Второй уровень назван управляемым (managed), а четвертый - управляемым на основе метрик (quantitatively managed).

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

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

CMMI.

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

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

• Управление проектом.

Включает планирование проектов (2), контроль хода проекта (2), управление соглашениями с поставщиками (2), интегрированное управление проектами (3), управление рисками (3), построение команд (3), управление поставщиками (3) и измерение показателей результативности и хода проекта (4).

• Технические.

52

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

• Поддерживающие.

2.5.2. Национальные стандарты на разработку ПО

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

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

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

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

В стандартах ЕСПД устанавливаются требования, регламентирующие разработку, сопровождение, изготовление и эксплуатацию программ, что обеспечивает возможность:

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

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

автоматизации изготовления и хранения программной документации.

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

53

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

В состав ЕСПД входят:

основополагающие и организационно-методические стандарты;

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

стандарты, обеспечивающие автоматизацию разработки программных документов. [4]

Обозначение национального стандарта РФ состоит из: -индекса ГОСТ Р; -регистрационного номера;

-четырёх цифр года принятия стандарта (двух цифр, если стандарт принят до 2000 г.).

Примеры

1ГОСТ Р 51898-2002

2ГОСТ Р 51121-97

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

Примеры

1 ГОСТ Р 1.5-2004

Если стандарт оформлен на основе аутентичного текста международного (регионального) стандарта, то обозначение состоит:

-из индекса ГОСТ Р;

-обозначения соответствующего международного (регионального) стандарта без года принятия;

-года принятия стандарта в РФ.

Например, обозначение ГОСТ Р ИСО 9001-2001.

54

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

Примеры:

1 ГОСТ 19.701-90 (ИСО 5807:85)

В своем большинстве требования ГОСТов носят методический характер и направлены на нормирование ПРОЦЕССА разработки, СОСТАВЛЕНИЯ ДОКУМЕНТАЦИИ и ТЕСТИРОВАНИЕ продукта. Поэтому все стандарты и нормативны можно разделить на две взаимодополняющие группы.

Группа 1: Программный продукт. Базовые документы.

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

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

3)Федеральный закон Российской Федерации от 26 июня 2008 года N 102-ФЗ Об обеспечении единства измерений.

4)Приказ №1081 от 30 ноября 2009 г. Об утверждении Порядка проведения испытаний стандартных образцов или средств измерений в целях утверждения типа, Порядка утверждения типа стандартных образцов или типа средств измерений, Порядка выдачи свидетельств об утверждении типа стандартных образцов или типа средств измерений, установления и изменения срока действия указанных свидетельств и интервала между поверками средств измерений, требований к знакам утверждения типа стандартных образцов или типа средств измерений и порядка их нанесения.

5)ГОСТ Р 8.654-2009 Требования к программному обеспечению средств измерений. Основные положения.

55

6)ГОСТ Р 8.596-2002 Метрологическое обеспечение измерительных систем. Основные положения.

7)ГОСТ Р ИСО/МЭК 17025-2006 Общие требования к компетентности испытательных и калибровочных лабораторий.

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

9)ГОСТ Р ИСО/МЭК 12119-2000 Информационная технология. Пакеты программ. Требования к качеству и тестирование.

10)ГОСТ Р ИСО 9127-94 Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов.

11)Рекомендация KOOMET R/LM/10:2004 Программное обеспечение средств измерений. Общие технические требования.

12)МИ 2955-2005 ГСИ. Типовая методика аттестации программного обеспечения средств измерений и порядок её проведения.

13)МИ 2174-91 ГСИ. Аттестация алгоритмов и программ обработки данных при измерениях. Основные положения.

Группа 2: Прочие документы. ГОСТы, МИ, рекоменда-

ции.

14)ГОСТ Р ИСО/МЭК ТО 12182-2002 Информационная технология. Классификация программных средств.

15)ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств.

16)ГОСТ Р ИСО/МЭК 14764-2002 Информационная технология. Сопровождение программных средств.

17)ГОСТ Р ИСО/МЭК 15026-2002 Информационная технология. Уровни целостности систем и программных средств.

56

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

19)ГОСТ Р ИСО/МЭК 15910-2002 Информационная технология. Процесс создания документации пользователя программного средства.

20)ГОСТ 19.001-77 Единая система программной документации. Общие положения.

21)ГОСТ 19.005-85 Единая система программной документации. Р-схемы алгоритмов и программ. Обозначения условные графические и правила выполнения.

22)ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам.

23)ГОСТ 19.301-79 ЕСПД. Программа и методика испытаний. Требования к содержанию и оформлению.

24)ГОСТ 19.505-79 ЕСПД. Руководство оператора. Требования к содержанию и оформлению.

25)ГОСТ 28195-89 Оценка качества программных средств. Общие положения.

26)ГОСТ 28195-99 Оценка качества программных средств. Общие положения.

27)ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.

28)ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

29)ГОСТ Р 51188-98 Защита информации. Испытания программных средств на наличие компьютерных вирусов. Типовое руководство.

30)ГОСТ Р 51189-98 Средства программные систем вооружения. Порядок разработки.

31)ГОСТ Р 51904-2002 Программное обеспечение встроенных систем. Общие требования к разработке и документированию.

57

32)ГОСТ Р ИСО/МЭК 8631-94 Информационная технология. Программные конструктивы и условные обозначения для их представления.

33)ГОСТ Р ИСО/МЭК ТО 9294-93 Информационная технология. Руководство по управлению документированием программного обеспечения.

34)ГОСТ 19.701-90 (ИСО 5807-85) ЕСПД. Схемы алгоритмов, программ, данных и систем. Обозначения условные и правила выполнения.

35)ГОСТ 34.320-96 Информационные технологии. Система стандартов по базам данных. Концепции и терминология для концептуальной схемы и информационной базы.

36)МИ 2546-99 ГСИ. Методы определения экономической эффективности метрологических работ.

37)МИ 2612-2000 ГСИ. Метрологические критерии оценки соответствия качества объекта сертификации нормативным требованиям.

38)Р 50.1.027-2001 - Информационные технологии поддержки жизненного цикла продукции. Автоматизированный обмен технической информацией. Основные положения и общие требования.

39)Р 50.1.028-2001 Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования.

40)Р 50.1.029-2001 Информационные технологии поддержки жизненного цикла продукции. Интерактивные электронные технические руководства. Общие требования к содержанию, стилю и оформлению.

41)Р 50.1.030-2001 Информационные технологии поддержки жизненного цикла продукции. Интерактивные электронные технические руководства. Требования к логической структуре базы данных.

42)Р 50.1.031-2001 Информационные технологии поддержки жизненного цикла продукции. Терминологический

58

словарь. Часть 1. Стадии жизненного цикла продукции. Часть 2. Терминология, относящаяся

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

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

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

59

3. АЛГОРИТМЫ И МЕТОДЫ ПРОЕКТИРОВАНИЯ ПРОГРАММ

3.1. Типы алгоритмов

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

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

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

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

60