Свой бизнес 

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

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

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

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

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

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

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

Процесс аудита – представляет собой определение соответствия требованиям, планам и условиям договора. Выполняется двумя сторонами договора, одна сторона проверяет другую.

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

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

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

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

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

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

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

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

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

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

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

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

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

18. Функциональные и нефункциональные требования. Управление требованиями.

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

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

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

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

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

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

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

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

19. Формализация, детализация и документирование требований:

Наиболее известный стандарт разработан IEEE и называется IEEE/ANSI 830-1993 предполагает следующую структуру спецификации :

1.Введение

1.1. Цели документа

1.2. Назначение программного продукта

1.3. Определения, акронимы и аббревиатуры

1.4. Список литературы и других источников

1.5. Обзор спецификации

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

2.1. Описание программного продукта

2.2. Функции программного продукта

2.3. Пользовательские характеристики

2.4. Общие ограничения

2.5. Обоснования, предположения и допущения

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

4. Приложения

5. Указатели

Таблица 4. Структура спецификации требований

20. Принципы проектирования интерфейса пользователя.

1. Принципы проектирования интерфейса пользователя:

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

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

Таблица 1. Принципы проектирования интерфейсов пользователя

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

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

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

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

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

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

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

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

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

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

21. Стратегия разработки интерфейса человек-компьютер.

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

Все виды взаимодействия можно отнести к одному из пяти основных стилей взаимодействия:

1. Непосредственное манипулирование. Пользователь взаимодействует с объектами на экране. Например, для удаления файла пользователь просто перетаскивает его в корзину.

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

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

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

5. Естественный язык. Пользователь вводит команду на естественном языке. Чтобы удалить файл, пользователь может ввести команду "удалить файл с именем XXX".

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

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

Таблица 2. Преимущества и недостатки стилей взаимодействия пользователя с системой

22. Составные части интерфейса: ввод-вывод, диалог, сообщения, проверка входных данных, подсказки. Разработка оконной системы.

Таблица 4. Элементы графических интерфейсов пользователя

Графические интерфейсы обладают рядом преимуществ:

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

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

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

На рис. 2 изображен итерационный процесс проектирования пользовательского интерфейса.

Рис. 2. Процесс проектирования интерфейса пользователя

23. Функциональная (алгоритмическая) декомпозиция системы.

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

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

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

  • каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);
  • каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.

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

24. Структурный подход к разработке ПО.

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

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

25. Принципы структурного подхода разработки ПО.

Все наиболее распространенные методы структурного подхода базируются на ряде общих принципов. Базовыми принципами являются:

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

Существуют еще принципы:

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

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

  • DFD (Data Flow Diagrams) – диаграммы потоков данных;
  • SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования) – модели и соответствующие функциональные диаграммы.
  • ERD (Entity-Relationship Diagrams) – диаграммы «сущность-связь ».

Диаграммы потоков данных и диаграммы «сущность-связь » - наиболее часто используемые в CASE –средствах виды моделей.

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

На стадии формирования требований к ПОSADT –модели и DFD используются для построения модели «AS-IS » и модели «TO-BE », отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов организации и взаимодействие между ними (использование SADT –моделей, как правило, ограничивается только данной стадией, поскольку они изначально не предназначались для проектирования ПО). С помощью ERD выполняется описание используемых в организации данных на концептуальном уровне, не зависимом от средств реализации базы данных (СУБД).

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

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

26. Восходящее проектирование ПО.

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

  • восходящий;
  • нисходящий.

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

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

Подход имеет следующие недостатки:

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

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

27. Нисходящее проектирование ПО

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

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

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

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

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

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

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

Нисходящий подход обеспечивает:

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

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

Метод SADT поддерживается Министерством обороны США, которое было иници-атором разработки стандарта IDEF0 (Icam DEFinition).

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

29. Принципы построения модели IDEF0.

Основные элементы этого метода основываются на следующих концепциях:

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

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

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

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

Состав функциональной системы:

Результатом применения метода SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции организации и интерфейсы на них представлены как блоки и дуги соответственно. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как входная информация, которая подвергается обработке, показана с левой стороны блока, а результаты (выход) показаны справой стороны. Механизм (человек или ав-томатизированная система), который осуществляет операцию, представляются дугой, входящей в блок снизу (рис.1):

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

30. Иерархия функциональных диаграмм.

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

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

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

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

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

31. Моделирование бизнес-процессов.

32. Основные принципы и технологии построения распределенных информационных систем.

Основные этапы проектирования базы данных:

Создание БД в среде системы управления базами данных предполагает выполнение следующих основных этапов:

· концептуальное проектирование;

· логическое проектирование;

· физическое проектирование;

· использование БД (заполнение БД информацией и формирование запросов и отчетов).

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

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

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

· описание логической структуры каждой таблицы;

· описание связей между таблицами, входящими в одну БД;

· первоначальное заполнение справочников БД необходимой нормативно-справочной информацией.

Что такое база данных

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

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

Все СУБД делятся на две группы: локальные и сетевые.

Локальные - это СУБД, работающие на одном компьютере. К ним относятся dBase, FoxPro, Microsoft Access и т. д.

Сетевые - это СУБД, позволяющие нескольким компьютерам использовать одну и ту же БД с помощью технологии клиент-сервер. Примерами сетевых СУБД являются InterBase, Oracle, Microsoft SQL Server и т. д.

Взаимосвязи данных:

· один к одному - каждая запись одного объекта БД будет указывать на единственную запись другого объекта;

· один ко многим - одной записи объекта БД будет соответствовать несколько записей других объектов;

· много к одному - равносилен рассмотренному выше виду «один ко многим» и отличается от него только направлением;

· много ко многим - устанавливается между двумя типами объектов БД. Например, когда у одного банкира может быть несколько клиентов и, одновременно, один клиент может пользоваться услугами нескольких банков.

33. Модели представления данных: реляционная, древовидная, сетевая.

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

Жизненный цикл что это такое в формальном понимании?

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

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

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

Начальные требования

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

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

Стандарты процессов жизненного цикла программного обеспечения

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

  • ГОСТ 34.601-90;
  • ISO/IEC 12207:2008;
  • Oracle CDM.

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

Виды ПО и апдейты

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

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

Пример на основе программы FL Studio

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

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

  • создание барабанного модуля по типу ритм-машин вроде Yamaha RX, но с применением one-shot-сэмплов или секвенций в формате WAV, записанных в студиях вживую;
  • интеграция в операционные системы Windows;
  • возможность экспорта проекта в форматах WAV, MP3 и OGG;
  • совместимость проектов с дополнительным приложением Fruity Tracks.

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

В связи с этим, на стадии тестирования и отладки разработчикам пришлось пойти по пути немецкой корпорации Steinberg и применить в требованиях к основному звуковому драйверу поддержку режима Full Duplex. Качество саунда стало выше и позволило изменять темп, высоту тона и накладывать дополнительные FX-эффекты в режиме реального времени.

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

Этим не ограничилось. На стадии управления проектом была введена поддержка подключения плагинов формата VST (сначала второй, а потом и третьей версии), в свое время разработанного компанией Steinberg. Грубо говоря, любой виртуальный синтезатор, поддерживающий VST-host мог подключаться к программе.

Неудивительно, что вскоре любой композитор мог использовать аналоги «железных» моделей, например, полные комплекты звуков некогда популярного Korg M1. Дальше - больше. Применение модулей вроде Addictive Drums или универсального плагина Kontakt позволило воспроизводить живые звуки реальных инструментов, записанных со всеми оттенками артикуляции в профессиональных студиях.

При этом разработчики постарались добиться и максимального качества, создав поддержку для драйверов ASIO4ALL, которые оказались на голову выше режима Full Duplex. Соответственно, повысился и битрейт. На сегодняшний день качество экспортируемого звукового файла может составлять 320 кбит/с при частоте дискретизации 192 кГц. А это профессиональный звук.

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

Перспективы развития

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

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

Даже в случае с ОС Windows такие тенденции можно заметить невооруженным взглядом. Вряд ли сегодня найдется хоть один юзер, использующий системы вроде модификаций 3.1, 95, 98 или Millennium. Их жизненный цикл закончился после выхода версии XP. Но вот серверные версии на основе технологий NT все еще актуальны. Даже Windows 2000 на сегодняшний день является не только весьма актуальной, но и по некоторым параметрам установки или безопасности даже превосходящей самые новые разработки. То же самое касается системы NT 4.0, а также специализированной модификации Windows Server 2012.

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

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

Некоторые дополнительные вопросы

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

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

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

Те же среды на основе Visual Basic остаются намного более популярными, нежели Windows-системы. А о прикладном ПО под UNIX-системы речь не идет вообще. Что говорить, если практически все коммуникационные сети тех же Соединенных Штатов работают исключительно на них. Кстати, системы вроде Linux и Android тоже изначально создавались именно на этой платформе. Поэтому, скорее всего, у UNIX перспектив намного больше, чем у остальных продуктов вместе взятых.

Вместо итога

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

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

К тому же, иногда жизненные циклы могут зависеть от актуальности средств разработки. Если, допустим, какой-то язык программирования устаревает, никто же не будет писать программы на его основе, и уж тем более - внедрять их в автоматизированные системы управления на производстве. Тут уже на первый план выходят даже не программисты, а маркетологи, которые должны своевременно реагировать на изменения компьютерного рынка. И таких специалистов в мире найдется не так уж и много. Высококвалифицированные кадры, способные держать руку на пульсе рынка, становятся наиболее востребованными. И именно они зачастую являются так называемыми «серыми кардиналами», от которых зависит успех или проигрыш определенного программного продукта в сфере IT.

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

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

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

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

Структура жизненного цикла по стандарту ISO/IEC 12207 базируется на трех группах процессов: основные, вспомогательные, организационные.

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

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

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

Процесс приобретения охватывает действия заказчика по приобретению ПП. К этим действиям относятся:

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

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

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

К этим действиям относятся:

  • 1) Инициирование поставки заключается в рассмотрении поставщиком заявочных предложений и принятия решения.
  • 2) Подготовка ответа на заявочные предложения выполняются в соответствии с принятыми решениями.
  • 3) Подготовка договора осуществляется после выбора заказчиком конкретного поставщика.
  • 4) Планирование выполняется после заключения договора и включает в селя следующие задачи: принятие решения поставщиком относительно выполнения работ своими силами или с подключением субподрядчика; разработку поставщиком плана управления проектом, содержащего организационную структуру проекта, разграничение ответственности, технические требования к среде разработки, управление субподрядчиками.
  • 5) Выполнение и контроль.
  • 6) Проверка и оценка.
  • 7) Поставка и завершение работ выполняется в соответствии с оговоренными в процессе инициирования действиями по приемки и завершении работ.

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

  • 1) Создание ПП и его компонентов с заданными требованиями, включая оформление проектной и эксплуатационной документации.
  • 2) Подготовку материалов, необходимых для проверки работоспособности и качества ПП.
  • 3) Подготовку материалов, необходимых для организации обучения персонала и т.д.

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

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

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

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

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

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

Этот процесс включает в себя:

  • 1) Подготовительную работу, которая требуется для определения и согласования необходимого перечня документов и документируемых процедур.
  • 2) Проектирование и разработку документации, которые выполняются в процессе работы над ПП и завершается одновременно с завершением его ЖЦ.
  • 3) Выпуск документации, который осуществляется по мере ее готовности.
  • 4) Сопровождение включает в себя действия по корректировки и обновлению документации в процессе жизненного цикла ПП.

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

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

Этот процесс включает в себя:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В данном разделе определены следующие вспомогательные процессы жизненного цикла:

  1. процесс документирования;
  2. процесс управления конфигурацией;
  3. процесс обеспечения качества;
  4. процесс верификации;
  5. процесс аттестации;
  6. процесс совместного анализа;
  7. процесс аудита;
  8. процесс решения проблем.

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

Данная организация организует и выполняет управление вспомогательным процессом на проектном уровне в соответствии с процессом управления (подраздел 7.1); определяет инфраструк­туру для данного процесса в соответствии с процессом создания инфраструктуры (подраздел 7.2);

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

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

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

  1. подготовка процесса;
  2. проектирование и разработка;
  3. выпуск;
  4. сопровождение.

6.1.1 Подготовка процесса

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

a) заголовок или наименование;

b) назначение;

c) пользователи документа;

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

e) сроки выпуска промежуточных и окончательных редакций.

6.1.2 Проектирование и разработка

Данная работа состоит из следующих задач:

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

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

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

6.1.З Выпуск

Данная работа состоит из следующих задач:

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

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

6.1.4 Сопровождение

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

6.2 Процесс управления конфигурацией

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

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

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

Список работ. Данный процесс состоит из следующих работ:

  1. подготовка процесса;
  2. определение конфигурации;
  3. контроль конфигурации;
  4. учет состояний конфигурации;
  5. оценка конфигурации;
  6. управление выпуском и поставка.

6.2.1 Подготовка процесса

Данная работа состоит из следующей задачи:

6.2.1.1 Должен быть разработан план управления конфигурацией. План должен определять:

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

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

6.2.2 Определение конфигурации.

Данная работа состоит из следующей задачи:

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

6.2.3 Контроль конфигурации

Данная работа состоит из следующей задачи:

6.2.3.1 Должны быть выполнены: обозначение и регистрация заявок на внесение изменений;

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

6.2.4 Учет состояний конфигурации

Данная работа состоит из следующей задачи:

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

6.2.5 Оценка конфигурации

Данная работа состоит из следующей задачи:

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

6.2.6 Управление выпуском и поставка

Данная работа состоит из следующей задачи:

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

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

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

Список работ. Данный процесс состоит из следующих работ:

  1. подготовка процесса;
  2. обеспечение продукта;
  3. обеспечение процесса;
  4. обеспечение систем качества.

6.3.1 Подготовка процесса

Данная работа состоит из следующих задач:

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

6.3.1.2 Процесс обеспечения качества должен быть скоординирован с соответствующими процессами верификации (подраздел 6.4), аттестации (подраздел 6.5), совместного анализа (подраз­дел 6.6) и аудита (подраздел 6.7).

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

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

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

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

d) ресурсы, графики и обязанности при проведении работ по обеспечению качества;

e) выбранные работы и задачи из вспомогательных процессов, таких как верификация (подраздел 6.4), аттестация (подраздел 6.5), совместный анализ (подраздел 6.6), аудит (подраздел 6.7) и решение проблем (подраздел 6.8).

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

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

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

6.3.2 Обеспечение продукта

Данная работа состоит из следующих задач:

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

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

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

6.3.3 Обеспечение процесса

Данная работа состоит из следующих задач:

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

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

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

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

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

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

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

Данная работа состоит из следующей задачи:

6.3.4.1 Должно быть обеспечено проведение дополнительных работ по управлению качеством в соответствии с разделами ГОСТ Р ИСО 9001, указанными в договоре.

6.4 Процесс верификации

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

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

Список работ. Данный процесс состоит из следующих работ:

  1. подготовка процесса;
  2. верификация.

6.4.1 Подготовка процесса

Данная работа состоит из следующих задач:

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

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

b) совершенства используемой технологии программирования и рисков, связанных с ее применением;

c) доступности фондов и ресурсов.

6.4.1.2 Если проект предусматривает работы по верификации, должен быть установлен про­цесс верификации для проверки программного продукта.

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

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

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

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

6.4.2 Верификация

Данная работа состоит из следующих задач:

6.4.2.1 Верификация договора

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

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

b) непротиворечивости требований и охвату ими потребностей пользователя;

c) наличия соответствующих процедур для внесения изменений в установленные требования и решения проблем;

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

e) наличия соответствующих критериев и процедур, предусмотренных в соответствии с установленными требованиями.

Примечание- Данная работа может выполняться при оценке договора (см. 6.3.1.3.b)].

6.4.2.2 Верификация процесса

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

a) соответствие и своевременность установления проектных требований к планированию;

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

c) применимость стандартов, процедур и условий к процессам проектирования;

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

6.4.2.3 Верификация требований

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

a) непротиворечивость, выполнимость и тестируемость требований к системе;

b) распределение требований к системе между объектами технических и программных средств и ручных операций в соответствии с проектом;

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

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

6.4.2.4 Верификация проекта

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

a) правильность проекта, его соответствие установленным требованиям и учет этих требова­ний в проекте;

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

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

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

6.4.2.5 Верификация программы

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

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

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

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

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

6.4.2.6 Верификация сборки

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

a) полнота и правильность сборки программных компонентов и модулей каждого программ­ного объекта в соответствующий программный объект;

b) полнота и правильность сборки технических и программных объектов и ручных операций в систему;

c) выполнение задач сборки в соответствии с планом сборки.

6.4.2.7 Верификация документации

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

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

b) своевременность подготовки документации;

c) соблюдение установленных процедур управления конфигурацией документов.

6.5 Процесс аттестации

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

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

Список работ. Данный процесс состоит из следующих работ:

  1. подготовка процесса;
  2. аттестация.

6.5.1 Подготовка процесса

Данная работа состоит из следующих задач:

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

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

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

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

a) объекты, подлежащие аттестации;

b) задачи, решаемые при аттестации;

c) ресурсы, обязанности и график при проведении аттестации;

d) процедуры передачи отчетов об аттестации заказчику и другим сторонам.

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

6.5.2 Аттестация

Данная работа состоит из следующих задач:

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

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

6.5.2.3 Проведение испытаний с учетом 6.5.2.1 и 6.5.2.2, включая:

a) испытания при критических, граничных и особых значениях исходных данных;

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

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

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

6.5.2.5 Испытание программного продукта в выбранных областях среды эксплуатации.

6.6 Процесс совместного анализа

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

6.1 Список работ.

Данный процесс состоит из следующих работ:

1) подготовка процесса;

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

3) технические анализы.

6.6.1 Подготовка процесса

Данная работа состоит из следующих задач:

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

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

6.6.1.3 Стороны должны согласовать следующие вопросы проведения каждого анализа: план проведения анализа; состав анализируемых программных продуктов (результатов работы) и про­блем; объем и процедуры проведения анализа; исходные и итоговые критерии при проведении анализа.

6.6.1.4 Проблемы, выявленные при проведении анализа, должны быть документально офор­млены и введены в процесс решения проблем (подраздел 6.8).

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

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

6.6.2 Анализы управления проектом

Данная работа состоит из следующих задач:

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

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

b) предложения по проведению общего контроля проекта посредством соответствующего перераспределения ресурсов;

c) предложения по изменению хода проекта или определению потребности в перепланирова­нии проекта;

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

6.6.3 Технические анализы

Данная работа состоит из следующих задач:

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

a) они полностью реализованы на данный момент;

b) они соответствуют принятым стандартам и техническим требованиям;

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

d) они полностью придерживаются установленных графиков работ;

e) они готовы к последующим работам;

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

6.7 Процесс аудита

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

Список работ. Данный процесс состоит из следующих работ:

  1. подготовка процесса;
  2. аудиторская проверка.

6.7.1 Подготовка процесса

Данная работа состоит из следующих задач:

6.7.1.1 Аудиторские проверки должны проводиться в сроки, установленные проектным планом(ами).

6.7.1.2 Аудиторский персонал не должен нести какой-либо прямой ответственности за прове­ряемые программные продукты и работы.

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

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

6.7.1.5 Проблемы, выявленные при проведении аудиторской проверки, должны быть доку­ментально оформлены и введены в процесс решения проблем (подраздел 6.8).

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

6.7.1.7 Стороны должны согласовать итоговый результат аудиторской проверки, любые при­нимаемые обязательства и критерии завершения аудиторской проверки. 6.7.2 Аудиторская проверка Данная работа состоит из следующей задачи:

6.7.2.1 Аудиторские проверки должны проводиться для обеспечения того, чтобы:

a) запрограммированные программные продукты (такие, как программный объект) отражали проектную документацию;

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

c) тестовые данные соответствовали установленным техническим требованиям;

d) программные продукты были успешно протестированы и соответствовали установленным к ним требованиям;

e) отчеты об испытаниях (тестировании) были правильны и расхождения между фактическими и ожидаемыми результатами были устранены;

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

g) работы были выполнены в соответствии с утвержденными требованиями, планами и договором;

h) стоимости и графики проведения работ соответствовали утвержденным планам.

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

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

Список работ. Данный процесс состоит из следующих работ:

  1. подготовка процесса;
  2. решение проблемы.

6.8.1 Подготовка процесса

Данная работа состоит из следующей задачи:

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

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

реализацию решения данных проблем и их внесение в соответствующие объекты; учет и докумен­тирование состояний проблем; сопровождение отчетов о проблемах;

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

c) в отчетах о проблемах должен быть приведен анализ причин их возникновения;

d) реализованные решения проблем и их введение в соответствующие объекты должны быть оценены по следующим критериям: какие проблемы решены; какие неблагоприятные причины их возникновения устранены; какие изменения правильно внесены в соответствующие программные продукты и работы; какие дополнительные проблемы обнаружены.

6.8.2 Решение проблемы

Данная работа состоит из следующей задачи:

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



error: Content is protected !!