Все о моделировании в Компас-3D LT
   Главная Статьи Файлы Форум Ссылки Категории новостей
June 23 2024 15:42:15   
Навигация
Главная
Статьи
Файлы
FAQ
Форум
Ссылки
Категории новостей
Обратная связь
Фото галерея
Поиск
Разное
Карта Сайта
Популярные статьи
Что необходимо ... 65535
4.12.1 Професси... 33251
Учимся удалять!... 32036
Примеры, синони... 23409
Просмотр готовы... 22684
Декартовы коорд... 22207
FAST (методика ... 21445
содержание - се... 20679
Просмотр готовы... 19347
Работа с инстру... 14791
Сейчас на сайте
Гостей: 1
На сайте нет зарегистрированных пользователей

Пользователей: 9,955
новичок: Logyattella
Друзья сайта
Ramblers Top100
Рейтинг@Mail.ru

Реклама
Выполняем курсовые и лабораторные по разным языкам программирования
Подробнее - курсовые и лабораторные на заказ по Delphi
Turbo Pascal, Assembler, C, C++, C#, Visual Basic, Java, GPSS, Prolog
8.1. Управление требованиями
Группа ключевых процессов для уровня 2: повторяемый уровень.
Цель управления требованиями состоит в том, чтобы заказчик и разработчики смогли полностью согласовать требования, выдвигаемые к проекту разработки ПО.
Управление требованиями включает в себя достижение и поддержку соглашения с заказчиком по требованиям к проекту разработки. Это соглашение носит название «системных требований, установленных для ПО». Под «заказчиком» может подразумеваться группа системного проектирования, группа маркетинга, какая-либо другая внутренняя организация или внешний заказчик. Данное соглашение охватывает как технические, так и прочие требования (например, сроки поставки). Это соглашение формирует основу для оценки затрат, планирования, выполнения и отслеживания производства работ по проекту в течение всего жизненного цикла ПО.
Отнесение системных требований к ПО, оборудованию и другим компонентам системы (например, людям) может выполняться группой, внешней по отношению к группе разработки (например, группой системного проектирования), причем разработчики не должны непосредственно контролировать это распределение. Группа разработки предпринимает в рамках проекта соответствующие шаги, обеспечивающие контроль над теми требованиями, которые попадают в сферу ответственности разработчиков, а также их документирование.
Чтобы обеспечить этот контроль, группа разработки рассматривает исходные и переработанные системные требования к ПО и пытается решить возможные проблемы до того, как требования будут внедрены в проект разработки. Любое изменение системных требований сопровождается изменениями затронутых планов разработки, промежуточных продуктов и операций в целях их согласования с обновленными требованиями.

Цели

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

Обязательства по выполнению 

Обязательство 1 Проект следует документу организационной политики управления системными требованиями, отнесенными к ПО.
В рамках этих практик системные требования, отнесенные к ПО, называются «установленными требованиями».
Установленные требования являются подмножеством системных требований, которые должны быть реализованы в программных компонентах системы. Установленные требования являются основной входной информацией для плана разработки ПО. Анализ требований к ПО позволяет конкретизировать, уточнить и документировать установленные требования.
Эта политика обычно состоит из следующих положений: 
1. Установленные требования должны быть документированы. 
2. Установленные требования рассматриваются:
    производственными менеджерами,
    другими задействованными группами.
Примеры групп, задействованных в проекте: 
группа системного тестирования, 
разработки ПО (включая все подгруппы, например, проектирования ПО), 
системного проектирования, 
обеспечения качества ПО, 
управления конфигурацией ПО, 
управления документацией.
3. Изменение установленных требований должно сопровождаться согласованными изменениями планов разработки, промежуточных продуктов и операций.
Комментарии
Нет комментариев.
Добавить комментарий
Пожалуйста залогиньтесь для добавления комментария.
Рейтинги
Рейтинг доступен только для пользователей.

Пожалуйста, залогиньтесь или зарегистрируйтесь для голосования.

Нет данных для оценки.
Гость
Имя

Пароль



Вы не зарегистрированны?
Нажмите здесь для регистрации.

Забыли пароль?
Запросите новый здесь.
Случайные статьи
ГЛАВА 6. СТРУКТУРА...
Характерис...
12.3.3.1 Выделени...
9. Продукции типа...
5.14 МОНТИРОВАНИЕ ...
Что для нас будет ...
ГЛАВА 12. МНОГОПРО...
Меры предосторожности
8.3.3 Построение п...
Что сделал Аристо...
2.6 УПРАЖНЕНИЯ
Представление домена
7.5. Применение пр...
Первая настройка с...
Глава 3. GARMIN ST...
6.4.5 Копирование ...
2.4.1 Кодирование ...
Данные, как главны...
Обратный синтаксис
3.10 Технологии To...
ВТОРОЙ ПРИМЕР
Экран отметки точек
1.5 Классификация...
Руководство по раз...
Что выбрать?
Среда передачи данных
Глава 4. Краткий ...
7.9 ЗАГРУЗКА СИСТЕ...
1.3.2 Среда выпол...
Глава 4. Я и GPS
7.3.5. Жизненные ц...
10.1.2.1 Open
3.2 СТРУКТУРА ОБЛ...
Электронный штурман
Приложения
Манчестерское коди...
4.7 ВЫДЕЛЕНИЕ ДИС...
Глава 14. КПК со в...
5.1 Архитектура со...
Характеристики при...
Мини-чат
Вам необходимо залогиниться.

Нет присланных сообщений.
Copyright © 2009