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

Введение

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

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

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

В связи с постоянным обновлением персональных компьютеров, соответственно, операционных сред и систем программирования, возникают сложности, связанные с адаптацией действующих программ и прикладных систем к новым условиям. В практике программирования не раз делались попытки облегчить труд по написанию программ, перейдя к "программированию без программистов". В связи с этим появлялись программные проекты, которые ставили своей целью заменить постановки задач математическим описанием и заставить машины их обрабатывать. К ним относятся компьютеризация математических знаний (машины серии "Мир", японский проект "ЭВМ 5-го поколения" [1.2]), фабрики программ по изготовлению программной продукции по типу сборочного конвейера из готовых "деталей"-программ (завод для сборки АСУ, система АПРОП, ПРИЗ) и многие другие проектные решения, направленные на изменение стилей программирования. Например, формальные спецификации и математическое доказательство правильности программ (1980 г.), систематизация знаний в области инженерии программного обеспечения и создание общего ядра знаний SWEBOK (2001, 2003гг.), теория построения и верификации программ (проект 2005 г.) и др.

Переворот в программировании по высвобождению армии пользователей компьютеров от разработки и написания программ так и не произошел, наоборот, методы и средства программирования постоянно развиваются. Особенно это связано с новыми возможностями платформ и распределенных сред, в которых компоненты располагаются по разным узлам сети и взаимодействуют между собой через сетевые протоколы. Кроме того, появились новые методы и подходы к разработке ПО: структурный, объектно-ориентированный, компонентный, аспектный, визуальный, агентно-ориентированный, сервисный и др. [1.3-1.12].

Для поддержки новых методов разработано огромное количество разнообразных инструментальных средств и методов оценки качества, производительности, стоимости и т.п. Процесс разработки ПО и методы оценивания продуктов стандартизованы (ISO/IEC 12207, 15504, 9126 и др.) [1.14, 1.16]. Все это способствует повышению эффективности проектирования, тестирования, прогнозирования надежности и оценки качества ПО.

Новый программный проект разрабатывается 1-2 года, а эволюционирует 6-7 лет. На сопровождение проекта тратится 61% против 39% средств на его разработку. Эффективность разработчиков в зависимости от квалификации колеблется в отношении 1:10, а значит, требуется повышать уровень знаний разработчиков ПО. На сегодня ядро стабильных знаний по программной инженерии составляет 75% от тех знаний, которыми пользуются в практической деятельности. В связи с этим проведена систематизация накопленных знаний в программировании и ряде других областей информатики. Международным комитетом при американском объединении компьютерных специалистов ACM (Association for Computing Machinery) и институте инженеров по электронике и электротехнике IEEE Computer Society было создано ядро знаний SWEBOK. В этом ядре были систематизированы разнородные знания в области программирования, планирования и управления, сформулировано понятие программной инженерии и десяти областей, которые соответствуют процессам проектирования ПО и методам их поддержки.

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

В этом определении выделим два основных аспекта.

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

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

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

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

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

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

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

1. менеджеры, которые планируют и руководят проектом, отслеживают сроки и затраты;

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

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

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

5. верификаторы, которые проверяют правильность реализации функций в проекте;

6. валидаторы, проверяющие ПО на соответствие заданным требованиям.

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

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

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

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

Для превращения программной инженерии в специальность мировая компьютерная общественность создала профессиональные комитеты, регламентирующие аспекты процесса программирования: ядро знаний SWEBOK, этический кодекс программиста [1.13], учебные курсы (Curricula -2001, 2004) по подготовке специалистов в области программной инженерии, обучение специальности и сертификация специалистов.

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

· значительным объемом накопленных знаний в области создания ПО;

· появлением новых методов анализа, моделирования и проектирования ПО;

· совершенствованием методов обнаружения ошибок в ПО;

· эффективной организацией коллективов разработчиков ПО и оценки их трудовой деятельности;

· использованием готовых программных компонентов, высокотехнологических средств и инструментов разработки ПО;

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

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

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

Содержание

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

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

o 1.1.2. Проектирование ПО (Software design)

o 1.1.3. Конструирование ПО (Software Construction)

o 1.1.4. Тестирование ПО (Software Testing)

o 1.1.5. Сопровождение ПО (Software maintenance)

o 1.1.6. Управление конфигурацией ПО

o 1.1.7. Управление инженерией ПО

o 1.1.8. Процесс инженерии ПО (Software Engineering Process)

o 1.1.9. Методы и инструменты инженерии ПО

o 1.1.10. Качество ПО (Software Quality)

· 1.2. Жизненный цикл ПС, связь с ядром знаний SWEBOK

· Контрольные вопросы и задания

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

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

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

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

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

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

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

· инженерия требований (Requirement Engineering),

· выявление требований (Requirement Elicitation),

· анализ требований (Requirement Analysis),

· спецификация требований (Requirement Specification).

· валидация требований (Requirement validation),

· управление требованиями (Requirement Management).

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

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

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

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

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

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

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

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

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

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

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

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

Управление конфигурацией (Software Configuration Management - SCM) состоит в идентификации компонентов системы, определении функциональных и физических характеристик аппаратного и программного обеспечения для контроля за внесением изменений и трассированием конфигурации на протяжении ЖЦ. Это управление соответствует одному из вспомогательных процессов ЖЦ (ISO/IEC 12207), выполняется техническим и административным руководством проекта; составляются отчеты об изменениях, внесенных в конфигурацию, и степени их реализации, а также проводится проверка соответствия внесенных изменений заданным требованиям.

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

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

Область знаний "Управление конфигурацией ПО" состоит из следующих разделов:

· управление процессом конфигурации (Management of SMC Process),

· идентификация конфигурации ПО (Software Configuration Identification),

· контроль конфигурации ПО (Software Configuration Control),

· учет статуса (положение конфигурации в ПО или состояние) конфигурации ПО (Software Configuration Status Accounting),

· аудит конфигурации ПО (Software Configuration Auditing),

· управление версиями ПО и доставкой (Software Release Management and Delivery).

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

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

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

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

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

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

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

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

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

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

Базис (baseline) - формально обозначенный набор элементов ПО, зафиксированный на этапах ЖЦ ПО.

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

Сборка ПО - объединение корректных элементов ПО и конфигурационных данных в единую исполняемую программу.

Управление инженерией ПО

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

Как любое управление, менеджмент ПО базируется на планировании, координации, измерении, контроле и учете процесса управления проектом. Координацию людских, финансовых и технических ресурсов при реализации задач программного проекта выполняет менеджер проекта, аналогично тому, как это делается в технических проектах. В его обязанности входит соблюдение запланированных бюджетных и временных характеристик и ограничений, стандартов и сформулированных требований. Общие вопросы управления проектом содержатся в ядре знаний РMBOK [1.21] в разделе Management Process Activities, а также в стандарте ISO/IEC 12207 - Software life cycle processes [1.14], где управление проектом рассматривается как дополнительный и организационный процесс ЖЦ.

Область знаний "Управление инженерией ПО (Software Engineering Management)" состоит из следующих разделов:

· организационное управление (Organizational Management),

· управление процессом и проектом (Process/Project Management),

· инженерия измерений ПО (Software Engineering Measurement).

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

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

В задачи управления проектом входят также уточнение требований, проверка их на соответствие заданным спецификациям характеристик качества, а также верификация функций отдельных продуктов проекта. Процесс управления проектом базируется на плановых сроках выполнения работ. Результаты планирования отображаются в сетевых диаграммах PERT (Program Evaluation and Review Technique), CРM (Сritical Path Method) и др., предназначенных для отображения всех аспектов работ, в частности, времени их выполнения и связей между разными работами в проекте.

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

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

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

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

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

Содержание

· 2.1. Процессы ЖЦ стандарта ISO/IEC 12207

· 2.2. Типы моделей ЖЦ

o 2.2.1. Каскадная модель ЖЦ

o 2.2.2. Инкрементная модель ЖЦ

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

o 2.2.4. Эволюционная модель ЖЦ

o 2.2.5. Стандартизация модели ЖЦ

· 2.3. Сопоставление ЖЦ стандарта ISO/IEC 12207 и областей SWEBOK

o 2.3.1. Характеристика процессов стандарта ISO/IEC 12207

o 2.3.2. Характеристика областей знаний SWEBOK

· Контрольные вопросы и задания

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

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

Исторически в эту схему работ включают:

· разработку требований или технического задания;

· разработку системы или технического проекта;

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

· пробную эксплуатацию;

· сопровождение и улучшение;

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

Основное назначение моделей ЖЦ состоит в следующем:

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

· обеспечение взаимодействия между разработчиками проекта и заказчиком;

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

· согласование промежуточных результатов с заказчиком;

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

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

· обсуждение используемых процессов ЖЦ в плане оценки их возможностей и недостатков, проявившихся при их применении, а также определение направлений усовершенствования или модернизации ЖЦ и др.

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

Типы моделей ЖЦ

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

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

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

Рис. 2.4. Каскадная модель ЖЦ программных систем

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

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

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

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

Недостатки этой модели:

· процесс создания ПС не всегда укладывается в такую жесткую форму и последовательность действий;

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

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

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

· требования к ПС недостаточно четко сформулированы, либо не учитывают перспективы развития ОС, сред и т.п.;

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

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

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

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

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

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

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

Инкрементная модель ЖЦ

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

Рис. 2.5. Инкрементная модель ЖЦ

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

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

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

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

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

· все возможности системы требуется реализовать с начала;

· быстрое изменение технологии и требований к системе может привести к нарушению полученной структуры системы;

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

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

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

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

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

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

Рис. 2.6. Спиральная модель ЖЦ разработки программных систем

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

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

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

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

Стандартизация модели ЖЦ

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

Модель данного ЖЦ включает в себя процессы:

· определение требований;

· разработка (проектирование, конструирование);

· верификация, валидация, тестирование;

· изготовление;

· эксплуатация;

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

Данной модели соответствуют все виды деятельности, начиная с разработки проекта или концепции программного продукта и заканчивая его изготовлением. Как было сказано выше, стандарт ISO/IEC 12207 объединяет эти виды деятельности в следующие три категории: основные, организационные и вспомогательные процессы, которые и составляют стандартный ЖЦ.

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

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

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

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

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

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

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

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

Содержание

· 3.1. Общие подходы к определению требований

o 3.1.1. Классификация требований

o 3.1.2. Анализ и сбор требований

o 3.1.3. Инженерия требований

o 3.1.4. Фиксация требований

o 3.1.5. Трассировка требований

· 3.2. Объектно-ориентированная инженерия требований

o 3.2.1. Сценарный подход

o 3.2.2. Описание требований прецедентами

· Контрольные вопросы и задания

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

Рис. 3.1. Основные разделы разработки требований

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

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

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

3.1. Общие подходы к определению требований

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

3.1.1. Классификация требований

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

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

Требования - это утверждения о функциях и ограничениях системы.

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

Требования - это спецификация того, что и как должно быть реализовано.

Согласно международному глоссарию по терминологии требования включают описание:

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

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

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

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

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

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

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

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

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

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

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

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

· конфиденциальность, безопасность и защиту данных;

· отказоустойчивость;

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

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

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

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

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

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

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

К выходному продукту предъявляются нефункциональные требования:

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

· к производительности (пропускная способность, время реакции и др.);

· к надежности выполнения (ошибки, интенсивность отказов и др.);

· к интерфейсным внешним атрибутам, с которыми взаимодействует система.

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

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

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

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

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

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

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

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

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

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

· спектра проблем ПрО, при решении которых будут реализованы услуги системы;

· функциональное содержание услуг;

· операционную среду работы системы.

В обсуждении требований на систему принимают участие:

· представители заказчика из нескольких профессиональных групп;

· операторы, обслуживающие систему;

· аналитики и разработчики будущей системы.

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

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

· неочевидные, не одинаково важные, которые брались из устаревших источников и документов заказчика;

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

· постоянно изменяемые, развиваемые и уточняемые;

· с уникальными свойствами или значениями;

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

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

· анализ проблем предметной области, потребностей заказчика и пользователей системы,

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

· внесение изменений в отдельные элементы требований.

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

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

Существующие стандарты (ГОСТ 34.601-90 и ГОСТ 34.201-89) на разработку требований к системе и документам фиксируют результаты создания программного, технического, организационного и др. видов обеспечения автоматизированных систем на этапах ЖЦ.

Сбор требований.Источниками сведений для формирования требований могут быть:

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

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

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

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

Методы сбора требований следующие:

· интервью с представителями интересов заказчика системы;

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

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

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

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

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

3.1.3. Инженерия требований

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

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

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

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

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

Основные задачи управления требованиями это:

· разработка атрибутов требований,

· управление вариантами требований,

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

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

· реализация требований на этапах ЖЦ.

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

Рис. 3.2. Разработка, управление требованиями и связь с задачами SWEBOK

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

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

3.1.4. Фиксация требований

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

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

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

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

3.1.5. Трассировка требований

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

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

Рис. 3.3. Типы трассируемости требований

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

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

· требования, которые изменяются при их формировании;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· ведение базы данных объектов трассировки и отношений между ними.

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

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

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

Рисунок 1.3. - Спиральная модель Боэма

Боэм сформулировал 10 наиболее распространенных рисков (по приоритетам):

1. Дефицит специалистов.

2. Нереалистичные сроки и бюджет.

3. Реализация несоответствующей функциональности.

4. Разработка неправильного пользовательского интерфейса.

5. Ненужная оптимизация и оттачивание деталей.

6. Непрекращающийся поток изменений.

7. Нехватка информации о внешних компонентах, определяющих окружение системы.

8. Недостатки в работах, выполняемых внешними по отношению к проекту ресурсами.

9. Недостаточная производительность получаемой системы.

10. «Разрыв» в квалификации специалистов разных областей знаний.

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

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

2. Анализ рисков - оценка альтернатив, выявление и снижение рисков.

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

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

Достоинства спиральной модели:

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

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

3. включает шаг системного подхода в итерационную структуру разработки;

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

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

Построение (Construction)

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

Внедрение (Transition)

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

RUP определяет следующие основные процессы (дисциплины):

1. моделирование бизнес-процессов;

2. управление требованиями;

3. анализ и проектирование;

4. реализация;

5. тестирование;

6. развертывание;

7. конфигурационное управление и управление изменениями;

8. управление проектом;

9. управление средой.

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

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

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

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

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

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

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

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

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

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

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

На основе итеративной/инкрементальной модели ЖЦ разработан главный конкурент RUP со стороны Microsoft – MSF (Microsoft Solutions Framework), а также аналогичный подход компании Borland – ALM (Application Lifecycle Management).

Метафора (metaphor) системы

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

Часовая рабочая неделя

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

Введение

В этом определении выделим два основных аспекта.

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

1. менеджеры, которые планируют и руководят проектом, отслеживают сроки и затраты;

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

5. верификаторы, которые проверяют правильность реализации функций в проекте;

6. валидаторы, проверяющие ПО на соответствие заданным требованиям.

· значительным объемом накопленных знаний в области создания ПО;

· появлением новых методов анализа, моделирования и проектирования ПО;

· совершенствованием методов обнаружения ошибок в ПО;

· эффективной организацией коллективов разработчиков ПО и оценки их трудовой деятельности;

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

Содержание

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

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

o 1.1.2. Проектирование ПО (Software design)

o 1.1.3. Конструирование ПО (Software Construction)

o 1.1.4. Тестирование ПО (Software Testing)

o 1.1.5. Сопровождение ПО (Software maintenance)

o 1.1.6. Управление конфигурацией ПО

o 1.1.7. Управление инженерией ПО

o 1.1.8. Процесс инженерии ПО (Software Engineering Process)

o 1.1.9. Методы и инструменты инженерии ПО

o 1.1.10. Качество ПО (Software Quality)

· 1.2. Жизненный цикл ПС, связь с ядром знаний SWEBOK

· Контрольные вопросы и задания

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

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

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

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

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

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

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

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

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

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

· инженерия требований (Requirement Engineering),

· выявление требований (Requirement Elicitation),

· анализ требований (Requirement Analysis),

· спецификация требований (Requirement Specification).

· валидация требований (Requirement validation),

· управление требованиями (Requirement Management).

12 3 4 5 6 7 8 9 10 Следующая ⇒

Последнее изменение этой страницы: 2019-03-31; Просмотров: 391; Нарушение авторского права страницы