Московский физико-технический институт
Опубликован: 24.09.2008 | Доступ: платный | Студентов: 74 / 26 | Оценка: 4.52 / 4.48 | Длительность: 25:15:00
Специальности: Системный архитектор
Лекция 2:

Области знаний программной инженерии и стандарты ЖЦ программного обеспечения

< Лекция 1 || Лекция 2: 123456 || Лекция 3 >
Аннотация: Дано определение программной инженерии, ее место в инженерной деятельности специалистов при создании компьютерных систем и общее описание десяти областей знаний профессионального ядра знаний SWEBOK. Изложен ЖЦ стандарта ISO/IEC 12207 и связь его процессов с областями знаний SWEBOK
Ключевые слова: ПО, рабочий продукт, ядро, ISO, определение, разбиение, связь, requirements engineering, requirements elicitation, requirements analysis, requirements management, реализация требований, software designer, представление архитектуры, архитектурный стиль, диаграммы активностей, язык спецификаций, ADL, ERD, диаграмма "сущность-связь", decision table, VDM, PDL, среда окружения, reduction, diversity, тестирование производительности, языки проектирования, APL, экстремальное программирование, extreme programming, унифицированный процесс, интеграционное тестирование, показатели надежности, интенсивность отказов, test level, test process, планирование процессов, defect, software maintenance, граф вызовов, SCM, configuration identification, configuration control, status accounting, configuration auditing, оценка продукта, engineering manager, software life cycle, сетевая диаграмма, PERT, метауровень, development process, maturity, SEI, bootstrapping, SPICE, ISO 9000, ISO 9001, проектная организация, engineering process, experimental, heuristic method, formal method, структурный метод, верификации программы, prove, спецификация программы, перспективная задача, requirements development, stage, трассировка требований, traceability, SADT, IDEF, program editor, code generator, development environment, test generator, test execution, test management tool, performance analysis, comprehensive, reverse engineering, software quality, quality assurance, usability, efficiency, оценка процесса, программная инженерия, предметной области, СУБД, модуль, управление данными, стоимость, таблица, пользователь, системное тестирование, архитектура, activity, работ, документирование, верификация, валидация, оценивание, управление проектом, менеджмент, контроль, подмножество, менеджер, эволюция, управление качеством, место

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

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

1.1 Анализ и характеристика областей знаний SWEBOK

Ядро знаний SWEBOK является основополагающим научно-техническим документом, который отображает мнение многих зарубежных и отечественных специалистов в области программной инженерии [1.3-1.12] и согласуется с современными регламентированными процессами ЖЦ ПО стандарта ISO/IEC 12207. В этом ядре знаний содержится описание 10 областей, каждая из которых представлена согласно принятой всеми участниками создания этого ядра общей схемы описания, включающей определение понятийного аппарата, методов и средств, а также инструментов поддержки инженерной деятельности. В каждой области описывается определенный запас знаний, который должен практически использоваться в соответствующих процессах ЖЦ.

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

Основные области знаний SWEBOK

увеличить изображение
Рис. 1.1. Основные области знаний SWEBOK
Организационные области знаний SWEBOK

увеличить изображение
Рис. 1.2. Организационные области знаний SWEBOK

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

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

1.1.1. Требования к ПО (Software Requirements)

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

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

Область знаний "Требования к ПО (Software Requirements)" состоит из следующих разделов:

  • инженерия требований (Requirement Engineering),
  • выявление требований (Requirement Elicitation),
  • анализ требований (Requirement Analysis),
  • спецификация требований (Requirement Specification).
  • валидация требований (Requirement validation),
  • управление требованиями (Requirement Management).

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

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

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

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

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

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

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

Спецификация требований к ПО - процесс формализованного описания функциональных и нефункциональных требований, требований к характеристикам качества в соответствии со стандартом качества ISO/IEC 9126-94, которые будут отрабатываться на этапах ЖЦ ПО. В спецификации требований отражается структура ПО, требования к функциям, качеству и документации, а также задается в общих чертах архитектура системы и ПО, алгоритмы, логика управления и структура данных. Специфицируются также системные требования, нефункциональные требования и требования к взаимодействию с другими компонентами и платформами (БД, СУБД, маршаллинг данных, сеть и др.).

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

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

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

< Лекция 1 || Лекция 2: 123456 || Лекция 3 >
Александр Медов
Александр Медов

Здравствуйте,при покупке печатной формы сертификата,будут ли выданы обе печатные сторны?

Александр Медов
Александр Медов

Здравствуйте, прошел курс МБА Управление ИТ-проектами и направил документы на получение диплома почтой. Подскажите, сроки получения оного в бумажной форме?

: