На начальном уровне процесс разработки программного продукта либо неустойчивый и хаотичный, либо про него ничего не известно. (На этот уровень попадают все предприятия-разработчики, поскольку на нем отсутствуют какие-либо требования к процессу.)
Уровень 2. Управляемый (Managed)
На втором уровне процесс разработки программного продукта становится управляемым. Предприятие, находящееся на втором уровне зрелости, добилось того, что все процессы планируются, документируются, выполняются, оцениваются и контролируются на уровне программных проектов.
Уровень 3. Определенный (Defined)
Для третьего уровня зрелости процесса характерно, что все виды деятельности, связанные с процессом, основаны на одном, общем для всего предприятия, стандартном наборе процессов, которые подогнаны под конкретные условия, хорошо понимаемы и описаны в корпоративных стандартах, руководствах и т.п. Разработанный на предприятии набор стандартных процессов постоянно усовершенствуется и является базисом для развития и внедрения согласованных процессов во всех проектах, которые ведутся на предприятии.
Разработка, анализ и управление требованиями очень важны в программном проекте, поэтому соответствующие ключевые области определены уже для второго и третьего уровней зрелости. Приведем список таких ключевых областей.
На втором уровне зрелости определены следующие ключевые области:
1.Управление требованиями (Requirements Management) – обеспечение возможности установления единого с заказчиком понимания требований к разрабатываемому продукту.
2.Управление конфигурацией (Configuration Management) – установление и поддержка целостности всех продуктов проекта или процесса за счет обеспечения единой системы идентификации компонентов продукта, контроля над изменениями и управления изменениями компонентов.
Третий уровень характеризуется включением ключевой области:
Разработка требований (Requirements Development)» – разработка и анализ требований заказчика, требований к программному продукту и отдельным его компонентам.
Для обеспечения данных ключевых областей перечислим [6] следующие специфические типы инструментов:
· моделирование требований;
· трассировка требований;
· управление версиями.
Существует взаимосвязь между уровнями зрелости и используемыми инструментами. Для этапа разработки требований набор инструментов, поддерживающий ключевые области процесса, приведен в таблице 8.1.
Таблица 8.1
| Уровень | Основная цель применения | Ключевые области процесса | Инструменты | Минимальный набор инструментов |
| 2 Повторяемый | Процесс осуществления менеджмента проектов | 1. Управление требованиями | 1.Моделирование требований | Visio, Access |
| 2. Трассировка | Excel | |||
| 2. Менеджмент конфигурации | 3. Управление версиями | Visual Source Safe |
8.2.1. Моделирование требований
Инструментальные средства управления требованиями можно разделить на две категории: моделирование и трассировку. Инструменты моделирования позволяют, используя графические средства, описать модель требования, а затем по определенным (в инструменте) правилам выполнить его структурное или объектно-ориентированное моделирование. Минимальный набор инструментов моделирования состоит из графического пакета Visio, позволяющего построить различные, например, IDF или UML модели требований, и базы данных Access, хранящей структурную информацию требований.
8.2.2. Трассировка требований
Возможности анализа требований и их реализации во многом определяются трассируемостью требований. Трассируемость должна позволять выполнять прослеживание как вперед, от требования до его кода, так и назад, от кода к требованию. Автоматизация трассировки требований становится особенно важной по мере роста сложности разрабатываемого программного продукта. Инструмент должен позволять уникально именовать требование и хранить его краткое описание. Минимальный набор инструментальных средств включает в себя Excel для хранения и управления матрицей трассируемости требований.
Управление версиями
Инструменты по управлению версиями используются на всех этапах жизненного цикла разработки программных продуктов. Управление версиями охватывает все промежуточные продукты (артефакты), создаваемые в процессе разработки, в том числе и требования.
8.3. Возможности CASE-средств управления требованиями
Коммерческие средства управления требованиями [4] позволяют определять различные типы требований: бизнес-требования, варианты использования, функциональные требования, ограничения и требования к оборудованию. Эти средства обладают большими возможностями определения атрибутов для перечисленных типов требований, что очень трудно сделать при использовании обычных средств документирования.
Большинство инструментальных средств управления требованиями может быть интегрировано с одной из самых используемых программ – Microsoft Word, что расширяет их возможности и упрощает внедрение. Они поддерживают иерархическую систему нумерации требований и их именование.
Инструментальные средства позволяют выводить требования в виде документа заданного формата или в виде табличного отчета.
Все инструментальные средства обладают широкими возможностями по трассированию требований, определению групп пользователей средства с различными правами доступа, включению графических объектов и т.д. Современные средства управления требованиями интегрируются с другими программными средствами, используемыми при разработке продукта.
Средства IDF-моделирования
Совокупность методик и моделей концептуального проектирования IDEF (Integrated DEFinition) была разработана в США. В настоящее время имеются методики функционального, информационного и поведенческого моделирования, в которые входит достаточно большое число моделей. Например:
1.IDEF0 – функциональное моделирование. Реализует методику функционального моделирования сложных систем, основой которой является методология SADT (Structured Analysis and Design Technique).
2.IDEF2, IDEF3 – поведенческое моделирование, или моделирование деятельности. В основе лежат модели и методы имитационного моделирования систем массового обслуживания, сети Петри, конечные автоматы.
Перечисленные методики относятся к структурным методам.
Platinum BPwin
Platinum BPwin – это наиболее распространенный пакет, поддерживающий технологию моделирования IDEF. В него включены три методологии моделирования: функциональное моделирование (IDEF0), описание бизнес-процессов (IDEF3) и диаграммы потоков данных (DFD).
При создании новой модели достаточно в начальном диалоге выбрать нужную методологию. Рабочий стол BPwin состоит из нескольких окон, панель меню соответствует стандартам Windows и обеспечивает доступ ко всем функциям, а стандартная панель инструментов обеспечивает быстрый доступ к часто выполняемым задачам. Особенностью BPwin является наличие дерева модели, которое позволяет просматривать (в разных режимах) созданные модели, действия и объекты диаграмм, согласно уровням их декомпозиции и т.д. В своем составе BPwin имеет программу «Наставник», позволяющую быстро ознакомиться с нужной методикой и ее реализаций в пакете.
BPwin позволяет печатать диаграммы и строить отчеты по моделям. Определено большое число стандартных отчетов, например:
· отчет по диаграммам, который включает информацию об объектах в активной диаграмме;
· отчет о связях в модели;
· отчет об объектах диаграммы, содержащий информацию об объектах, размещенных на диаграмме (функциональных блоках, хранилищах данных и внешних ссылках);
· отчет о целостности модели, определяющий степень соответствия активной модели и выбранной методологии.
Более подробное описание пакета BPwin и его применения для моделирования (требований) можно найти в [5].
Средства UML
В разделе 4 мы уже касались унифицированного языка моделирования UML, который является графическим языком моделирования общего назначения, предназначенного для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых при разработке приложений.
UML имеет средства – диаграммы использования – для общего представление функционального назначения системы ее положения во внешнем мире. Для описания варианта использования используются другие средства, например, диаграммы состояний и диаграммы последовательности.
Rational Rose
Пакет Rational Rose – мощный инструмент анализа и проектирования объектно-ориентированных программных систем. Модель Rose [2] поддерживает четыре представления: представление вариантов использования, логическое представление, представление компонентов и представление размещения.
Представление вариантов использования содержит: действующих лиц, взаимодействующих с системой, варианты использования, являющиеся элементами функциональности системы, документацию, детализирующую происходящие в вариантах использования процессы и диаграммы использования, отображающие действующих лиц, варианты использования и взаимодействие между ними. В данное представление входят диаграммы взаимодействия, отображающие объекты или классы, которые принимают участие в одном потоке событий варианта использования. Для каждого варианта использования можно создать множество диаграмм взаимодействия. Представление вариантов использования содержит пакеты, являющиеся группами вариантов использования и/или действующих лиц.
Представление вариантов использования необходимо заказчикам, аналитикам (разработчикам требований) и менеджерам проектов. Анализируя это представление, эти (заинтересованные) лица могут прийти к соглашению о том, как может выглядеть система на высоком уровне, достичь понимания системы на высоком уровне.
Together
Программный пакет Together позволяет:
1. Представлять требования в виде диаграмм использования или в списках системных свойств, связывая их гиперссылками.
2. Строить диаграммы видов деятельности, связанные с требованиями, представленными диаграммами использования или свойствами.
3. Использовать для описания взаимодействия диаграммы последовательности, строить диаграммы состояний, а также наборы тестов.
В основе Together лежат следующие идеи:
1. Поддержка одной централизованной модели, что позволяет достичь взаимной согласованности проектной документации и исходного кода системы.
2. Сотрудничество с использованием средств управления конфигурацией, что позволяет использовать один механизм для управления моделями, документами и исходным кодом.
3. Автоматизация рутинных операций.
4. Постоянный контроль качества. Аудит позволяет проверить соответствие стандартам, используя встроенные правила или формулируя свои правила контроля. Применяя метрики, определенные в Together, можно провести количественный анализ исходного кода.
Достаточно подробное описание Together и его использование в процессе разработки программных систем можно найти в [6].
Вопросы для самоконтроля
1.Какие недостатки имеет документальное хранение требований?
2.Почему используются CASE-средства управления требованиями?
3.Отчего зависит внедрение автоматизации в процесс управления требованиями?
4.Какие ключевые области процесса, которые определены для разработки требований и на каком уровне зрелости?
5.Какие типы инструментов используются для обеспечения данных ключевых областей?
6.Какие инструменты поддерживают модели концептуального проектирования IDEF ?
7.Что представляет собой пакет Rational Rose?
8.Какие идеи лежат в основе пакета Together?
Список литературы
1. Брауде Э. Технология разработки программного обеспечения. – Спб.: Питер, 2004.
2. Боггс Уэнди. UML и Rational Rose 2002 – М.: Лори-Пресс , 2004
3. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. – М.: ДМК, 2000.
4. Вигерс К. Разработка требований к программному обеспечению /Пер. с англ. – М.: Издательско-торговый дом «Русская редакция», 2004.
5. Дубейковский В. И. Практика функционального моделирования с AllFusion Process Modeler 4.1. Где? Зачем? Как? – М.: ДИАЛОГ-МИФИ, 2004.
6. Кармайкл Э., Хейвуд Д. Быстрая и качественная разработка программного обеспечения : Пер. с англ. – М.: Издательский дом «Вильямс», 2003.
7. Коберн А. Современные методы описания функциональных требований к системам. – М.: Издательство “Лори”, 2002.
8. Константайн Л., Локвуд Л. Разработка программного обеспечения. – СПб.: Питер, 2004.
9. Соммервилл И. Инженерия программного обеспечения, 6-ое издание. : Пер. с англ. – М.: Издательский дом «Вильямс», 2002.
10. Шафер Д., Фатрелл Р., Шафер Л. Управление программными проектами: достижение оптимального качества при минимуме затрат. : Пер. с англ. –М.: Издательский дом «Вильямс», 2003
Карта памяти к разделу 1
Карта памяти к разделу 2
Карта памяти к разделу 3
Карта памяти к разделу 4
Карта памяти к разделу 5
Карта памяти к разделу 6
Карта памяти к разделу 7
Карта памяти к разделу 8
Содержание
1. Виды, взаимосвязь и свойства требований. 1
1.1. Что такое «требование»?. 1
1.2. Виды требований. 2
1.2.1. Функциональные требования. 3
1.2.2. Нефункциональные требования. 4
1.3. Свойства требований. 6
1.3.1. Полнота и корректность. 6
1.3.2. Необходимость и осуществимость. 7
1.3.3. Приоритет. 7
1.3.4. Недвусмысленность и непротиворечивость. 7
1.3.5. Проверяемость и прослеживаемость. 7
1.4. Особенности разработки требований к программным системам. 7
1.5. Вопросы для самоконтроля. Ошибка! Закладка не определена.
2. Определение образа и границ проекта. 9
2.1. Анализ предметной области. 9
2.2. Анализ осуществимости. 10
2.3. Определение целей и области действия. 11
2.4. Документирование образа и границ проекта. 12
2.5. Вопросы для самоконтроля. 14
3. Выявление требований. 14
3.1. Определение способа сбора и анализа требований. 15
3.1.1. Источники возникновения требований. 15
3.1.2. Заинтересованные в проекте лица. 15
3.2. Опрос (интервью) 16
3.2.1. Подготовка. 16
3.2.2. Проведение опроса. 17
3.2.3. Определение последующих действий. 18
3.3. Совместные семинары.. 19
3.4. ”Мозговой штурм”. 20
3.4.1. Роли во время сеансов. 20
3.4.2. Правила проведения сеанса. 20
3.4.3. Подготовка к сеансу. 21
3.4.4. Проведение сеанса. 22
3.4.5. Обработка результатов сеанса. 22
3.5. Сценарии. 23
3.5.1. Сценарии событий. 23
3.5.2. Варианты использования. 25
3.5.3. Применение модели MSC UML. 27
3.6. Выявление требований на основе различных точек зрения. Метод VORD 28
3.6.1. Идентификация точек зрения. 29
3.6.2. Структурирование точек зрения. 30
3.6.3. Документирование и отображение системы точек зрения. 30
3.7. Этнографический подход. 32
3.8. Вопросы для самоконтроля. Ошибка! Закладка не определена.
4. Разработка системных требований. 33
4.1. Детализация требований пользователей. 34
4.2. Системные модели. 34
4.2.1. Модели потоков данных. 36
4.2.2. Модели конечных автоматов. 38
4.2.3. Модели данных. 39
4.3. Прототипы.. 41
4.3.1. Роль прототипов при разработке требований. 41
4.3.2. Виды прототипов. 42
4.4. Разработка прототипов. 42
4.4.1. Экспериментальное прототипирование. 43
4.4.2. Эволюционное прототипирование. 43
4.4.3. Риски прототипирования. 44
4.5. Системные требования. 45
4.5.1. Структурированный естественный язык. 46
4.5.2. Языки описания программ. 46
4.5.3. Графические нотации. 47
4.6. Документирование системных требований. 48
4.7. Вопросы для самоконтроля. 48
5. Документирование требований. 48
5.1. Спецификация требований. 48
5.2. Состав спецификации требований. 49
5.3. Рекомендации по разработке требований. 51
5.4. Стандартные шаблоны спецификации. 52
5.5. Вопросы для самоконтроля. 57
6. Анализ спецификации требований. 57
6.1. Оценка качества спецификации требований. 57
6.1.1. Характеристики качества спецификации. 57
6.1.2. Аттестация требований. 58
6.2. Экспертиза спецификации. 58
6.3. Прототипирование. 61
6.4. Автоматизированный анализ. 61
6.5. Тестирование требований. 61
6.6. Вопросы для самоконтроля. 63
7. Управление требованиями. 63
7.1. Причины изменений требований. 64
7.2. Принципы управления требованиями. 65
7.3. Управление изменениями. 68
7.4. Управление версиями. 70
7.5. Управление связями требований. 70
7.6. Риски, связанные с требованиями. 72
7.6.1. Риски этапа выявления требований. 73
7.6.2. Риски этапа анализа и спецификации требований. 74
7.6.3. Риски управления требованиями. 75
7.7. Вопросы для самоконтроля. 75
8. CASE-средства для управления требованиями. 76
8.1. Выбор CASE-средств для управления требованиями. 76
8.2. Уровень зрелости и используемые инструменты.. 77
8.2.1. Моделирование требований. 79
8.2.2. Трассировка требований. 79
8.2.3. Управление версиями. 79
8.3. Возможности CASE-средств управления требованиями. 79
8.3.1. Средства IDF-моделирования. 80
8.3.2. Средства UML. 81
8.4. Вопросы для самоконтроля. 83
Список литературы.. 83
Карта памяти к разделу 1. 84
Карта памяти к разделу 2. 85
Карта памяти к разделу 3. 86
Карта памяти к разделу 4. 87
Карта памяти к разделу 5. 88
Карта памяти к разделу 6. 89
Карта памяти к разделу 7. 90
Карта памяти к разделу 8. 91
Дата: 2018-11-18, просмотров: 255.
