Все о моделировании в Компас-3D LT
   Главная Статьи Файлы Форум Ссылки Категории новостей
November 03 2024 09:08:51   
Навигация
Главная
Статьи
Файлы
FAQ
Форум
Ссылки
Категории новостей
Обратная связь
Фото галерея
Поиск
Разное
Карта Сайта
Популярные статьи
Что необходимо ... 65535
4.12.1 Професси... 34113
Учимся удалять!... 32256
Примеры, синони... 23563
Просмотр готовы... 22854
Декартовы коорд... 22536
FAST (методика ... 21600
содержание - се... 20903
Просмотр готовы... 19603
Работа с инстру... 15059
Сейчас на сайте
Гостей: 1
На сайте нет зарегистрированных пользователей

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

Реклама
Выполняем курсовые и лабораторные по разным языкам программирования
Подробнее - курсовые и лабораторные на заказ по Delphi
Turbo Pascal, Assembler, C, C++, C#, Visual Basic, Java, GPSS, Prolog
9.4. Интегрированное управление разработкой ПО

Примеры принимаемых мер: 
анализ и моделирование компромиссных вариантов функций, качества, затрат, графика, персонала и других ресурсов; 
определение страховочных действий и, по возможности, внесение резерва времени в график; 
оценка влияния предполагаемых действий на все критические зависимости; 
распространение информации о принятых решениях между всеми задействованными группами.
Операция 10 Выявление, оценка, документирование рисков проекта разработки и управление ими проводится в соответствии с документированной процедурой.
Основные практики, связанные с выявлением и отслеживанием рисков, содержатся в описании Операции №13 группы ключевых процессов «Планирование проекта» и Операции №10 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».
Примеры областей, в которых риски могут с большой вероятностью привести к срыву проекта: календарный график, затраты, функциональные возможности разрабатываемой системы, пропускная способность или реальная производительность, надежность и доступность, использование критических компьютерных ресурсов.
Примеры работ по управлению рисками: раннее выявление проектных задач с высокой степенью риска; определение событий, порождающих риски или повышающих их вероятность; создание прототипов или ранняя реализация модулей с высокой степенью риска; тщательное отслеживание индикаторов ключевых рисков проекта.
Эта процедура обычно определяет следующее:
1. Документируется план управления рисками разработки, который затем используется для выявления рисков и управления ими.
Примеры вопросов, рассматриваемых в плане управления рисками:
необходимые ресурсы (включая персонал и инструментальные средства);
методы управления рисками (т. е. выявление, анализ, определение приоритетов, планирование, мониторинг и устранение);
список выявленных рисков (включая оценку, приоритет, статус и планируемые действия);
график управления рисками;
обязанности и полномочия; метод и периодичность распространения информации о статусе рисков и связанных с ними мероприятиях;
измерения.
2. Планирование страховочных действий основывается на производственном процессе проекта и выполняется в течение всего жизненного цикла разработки.
Примеры областей, в которых проводится планирование страховочных действий:
определение вариантов,
оценка влияния вариантов,
техническая осуществимость вариантов,
распределение резервов управления,
критерии принятия решений о реализации вариантов.
3. Для каждого риска разработки, по возможности, определяются альтернативные решения и критерии выбора альтернатив.
4. Первый вариант и основные изменения плана по управлению рисками проходят экспертную оценку.
См. группу ключевых процессов «Экспертные оценки».
5. Документ плана управления рисками должен быть управляемым и контролируемым.
6. Риски отслеживаются, переоцениваются и перепланируются на определенных этапах проекта, в определенных точках контроля рисков и при планировании значительных изменений, влияющих на проект разработки ПО.
При проведении этих переоценок проверяются и пересматриваются приоритеты рисков и планы по управлению рисками.
Информация, полученная при отслеживании рисков, используется для уточнения оценок рисков и планов по управлению рисками.
7. Группа разработки ПО, а также другие задействованные группы и отдельные лица должны получать информацию о рисках разработки, планах по управлению рисками и результатах действий по снижению рисков.
Примеры групп и отдельных лиц, задействованных в проекте:
заказчик,
субподрядчики,
конечные пользователи,
группа оценки объема составляющих проекта,
системного проектирования,
системного тестирования,
обеспечения качества ПО,
управления конфигурацией ПО,
управления договорами,
управления документацией.
Операция 11 Периодически выполняются проверки проекта в целях определения действий, требуемых для приведения в соответствие хода и результатов разработки с текущими и планируемыми потребностями бизнеса, заказчика и конечных пользователей.
Примеры действий:
ужесточение календарного графика,
изменение системных требований в ответ на изменения рыночной ситуации или потребностей заказчика и конечных пользователей,
прекращение проекта.
В этих практиках термином «конечные пользователи» называются конечные пользователи, определенные заказчиком, либо их представители.

Измерения и анализ

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

Проверка внедрения

Проверка 1 Регулярная проверка высшим руководством выполнения работ по управлению проектом.
Практики, связанные со стандартным содержанием проверок со стороны высшего руководства, содержатся в описании Проверки №1 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».
Проверка 2 Регулярные и событийные проверки менеджером проекта работ по управлению проектом.
Практики, связанные со стандартным содержанием проверок со стороны руководства проекта, содержатся в описании Проверки №2 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».
Проверка 3 Выполнение группой обеспечения качества (SQA) проверок и/или аудитов работ и промежуточных продуктов по управлению проектом и составление отчетов по их результатам.
См. группу ключевых процессов «Обеспечение качества ПО».
Как минимум, проверяется следующее:
1. Процесс разработки и пересмотра производственного процесса проекта.
2. Процесс подготовки планов разработки ПО и управления рисками.
3. Процессы управления проектом в соответствии с его производственным процессом.
4. Процессы сбора и предоставления соответствующих данных для базы данных ППО.
5. Процесс использования базы данных ППО для поддержки работ по планированию, проведению оценочных расчетов и слежению за ходом проекта.
Страница 4 из 4 < 1 2 3 4
Комментарии
Нет комментариев.
Добавить комментарий
Пожалуйста залогиньтесь для добавления комментария.
Рейтинги
Рейтинг доступен только для пользователей.

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

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

Пароль



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

Забыли пароль?
Запросите новый здесь.
Случайные статьи
Использование согл...
2.4.7.1 Идея цикли...
9.1 СВОПИНГ
2.2.2.4 «Сон» и пр...
TDK XS-iV Tremor M...
2.6.2.3 Формирован...
Как показывать мод...
Почему САПР не "эл...
6. Программные про...
Глава 14. INTERPHA...
Пройдусь по Абрико...
Больше 500 долларов
Глава 6. HUMMINBIR...
6.6.2 Алгоритмы пр...
Video Logic DigiTh...
5.13 DUР
ГЛАВА 6. СТРУКТУРА...
2.3.3.3 Импульсная...
7.7 ИЗМЕНЕНИЕ РАЗМ...
содержание - сетев...
8.1.6 Работа в реж...
1.1. Основные понятия
8.3. Отслеживание...
7.4 ОЖИДАНИЕ ЗАВЕР...
4. Структура реинж...
Подходы к определе...
Второй параграф
5.18 СОПРОВОЖДЕНИЕ...
Вспомогательные ...
13.4 РАСПРЕДЕЛЕННА...
8.3.2 Внутренние с...
5.12.1 Системная ф...
Глава 9. Humminbir...
3. SADT-технология...
Качество приема
Глава 18. GSM/GPS-...
Подсхемы
Яблочная сеть
Размер и форма блоков
Использование подт...
Мини-чат
Вам необходимо залогиниться.

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