Все о моделировании в Компас-3D LT
   Главная Статьи Файлы Форум Ссылки Категории новостей
Август 15 2020 05:05:24   
Навигация
Главная
Статьи
Файлы
FAQ
Форум
Ссылки
Категории новостей
Обратная связь
Фото галерея
Поиск
Разное
Карта Сайта
Популярные статьи
Что необходимо ... 65535
Учимся удалять!... 26752
4.12.1 Професси... 24175
Примеры, синони... 21703
FAST (методика ... 19833
Просмотр готовы... 19564
Декартовы коорд... 18357
Просмотр готовы... 16494
содержание - се... 13906
Работа с инстру... 12492
Сейчас на сайте
Гостей: 1
На сайте нет зарегистрированных пользователей

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

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

Операция 6 Управление объемом промежуточных программных продуктов (или объемом их изменений) в соответствии с документированной процедурой.
Основные практики, связанные с планированием проекта и отслеживанием объема промежуточных программных продуктов, содержатся в описании Операции №9 группы ключевых процессов «Планирование проекта» и Операции №5 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».
Эта процедура обычно определяет следующее:
1. Независимая от разработчиков группа проверяет процедуры оценки объема промежуточных программных продуктов и дает рекомендации по использованию статистической информации из базы данных ППО для получения достоверных оценок.
Примером независимой группы может служить группа выполнения оценочных расчетов для составляющих проекта.
Примером метода определения достоверности оценок объема ПО может служить функциональное сравнение проектируемой системы с законченной.
Сотрудники, подготавливающие оценки объема, должны обеспечить соответствующий выбор процедур и данных, используемых при оценках.
Если достоверность оценки объема оказывается спорной, эта оценка проверяется группой экспертов.
2. При оценке объема каждого элемента ПО учитывается фактор непредвиденности, идентифицируемый как риск разработки.
Обоснование непредвиденных обстоятельств должно документироваться.
Оцениваются и документируются риски, связанные со снижением или устранением непредвиденности.
3. Определяются приобретаемые или повторно используемые программные компоненты.
Оценивается возможность повторного использования требований, архитектуры, кода, планов и процедур тестирования и т. п.
При оценках объема учитывается фактор трудоемкости модификации и внедрения повторно используемых компонентов.
4. Определяются и тщательно отслеживаются факторы, способные оказать значительное влияние на объем промежуточных программных продуктов.
5. Для каждого управляемого элемента ПО устанавливается предельный объем, в случае ожидаемого превышения которого требуется принятие соответствующих мер.
Операция 7 Управление трудоемкостью и себестоимостью разработки проводится в соответствии с документированной процедурой.
Основные практики, связанные с планированием и отслеживанием затрат на разработку и ее трудоемкости, содержатся в описании Операции №10 группы ключевых процессов «Планирование проекта» и
Операции №6 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».
Эта процедура обычно определяет следующее:
1. В случае использования моделей расчета затрат на разработку, ее трудоемкости и профиля укомплектования персоналом, они адаптируются к проекту и используют, при необходимости, доступные статистические данные.
2. Справочные данные по продуктивности и затратам корректируются с учетом характеристик проекта.
Примеры характеристик проекта:
географическое расположение проектных групп и организаций (например, субподрядчика),
объем и сложность системы,
стабильность требований,
хост-среда разработки,
целевая среда системы,
знание и опыт разработчиков, касающиеся создаваемого приложения,
доступность ресурсов,
другие специфические ограничения.
3. В целях эффективного управления проектными работами и затратами, их общий объем распределяется по отдельно управляемым задачам или стадиям.
4. При проверке статуса вложенных трудозатрат и финансовых расходов и последующем пересмотре оценок фактические расходы относительно выполненной на данный момент работы сравниваются с планом разработки ПО. Результаты сравнения используются для уточнения оценок трудоемкости оставшейся работы и связанных с ней затрат.
При крупных изменениях требований к ПО обновляются значения параметров моделей, использующихся для оценки трудоемкости и себестоимости разработки.
По возможности в дальнейших расчетах используются фактические данные о продуктивности проекта и новые значения затрат на разработку.
5. Для каждой отдельно управляемой задачи или стадии устанавливаются предельные значения трудоемкости и затрат, при превышении которых требуется принятие соответствующих мер.
Операция 8 Управление использованием критических компьютерных ресурсов проекта проводится в соответствии с документированной процедурой.
Основные практики, связанные с планированием и отслеживанием критических компьютерных ресурсов, содержатся в описании Операции №11 группы ключевых процессов «Планирование проекта» и Операции №7 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».
Эта процедура обычно определяет следующее:
1. Оценки использования критических компьютерных ресурсов проекта могут выводиться на основании прежнего опыта, моделирования, прототипов или результатов анализа.
Документируются источники и обоснования оценок.
Оцениваются и документируются сходства и различия между проектами и источниками статистических данных с точек зрения предметной области и выбора архитектуры.
Документируются обоснования, позволяющие судить о достоверности оценочных расчетов.
2. Планируемые компьютерные ресурсы, системные требования, отнесенные к ПО, сами требования к ПО и/или архитектура ПО корректируются с учетом требований к критическим компьютерным ресурсам.
3. Доступные компьютерные ресурсы распределяются по компонентам ПО.
4. При проведении начальных оценок доступных критических компьютерных ресурсов предусматривается создание определенного резерва.
5. Для каждого критического компьютерного ресурса устанавливается предельное значение его использования, при ожидаемом превышении которого требуется принятие соответствующих мер.
Операция 9 Управление критическими зависимостями и последовательностями календарного графика проектных работ происходит в соответствии с документированной процедурой.
Основные практики, связанные с обсуждением и отслеживанием критических зависимостей, содержатся в описании Операции №12 группы ключевых процессов «Планирование проекта», Операции №8 группы ключевых процессов «Отслеживание хода проекта и контроль над ним» и Операции №4 группы ключевых процессов «Межгрупповая координация».
Эта процедура обычно определяет следующее:
1. Этапы, задачи, обязательства, критические зависимости, укомплектование персоналом, затраты и проверки распределяются в графике в соответствии с производственным процессом проекта.
Календарный график разработки идентифицирует конкретные задачи и этапы, чье завершение можно определить объективно (т. е. возможно бинарное определение в виде «да/нет»).
Для учета потребностей различных групп и сотрудников разрабатываются различные уровни детализации графика, связанные друг с другом соответствующим образом.
2. Определяются и обсуждаются критические зависимости, после чего они отражаются в календарном графике разработки.
Критические зависимости могут возникать как внутри группы разработки ПО (т. е. между подгруппами), так и между группой разработки и другими задействованными группами.
3. Определяются критические последовательности, после чего они отражаются в календарном графике разработки. 4. Критические зависимости проекта и критические последовательности календарного графика регулярно отслеживаются. 5. Для каждой критической последовательности устанавливается специфический документированный пороговый критерий, при ожидаемом превышении которого требуется принятие соответствующих мер.
Страница 3 из 4 < 1 2 3 4 >
Комментарии
Нет комментариев.
Добавить комментарий
Пожалуйста залогиньтесь для добавления комментария.
Рейтинги
Рейтинг доступен только для пользователей.

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

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

Пароль



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

Забыли пароль?
Запросите новый здесь.
Случайные статьи
ГЛАВА 4. ВНУТРЕННЕ...
Глава 19. GSM/GPS-...
7.3.8. Сбор и анал...
Атрибут
Код Хемминга
Одометр
Вместо заключения
Частотная и фазова...
7.8 КОМАНДНЫЙ ПРОЦ...
3.5 Проект станда...
Топология “звезда”
12.2 ГЛАВНЫЙ И ПОД...
Дисциплина идентиф...
10.4.2 Анализ потоков
3.2.1. Компоненты ЛВС
2.3.3.4 Импульсно-...
2.4.8 Итеративные ...
Cetus GPS
Синтез
От Аристотеля до ...
6.4.1 Прерывания и...
ОГЛАВЛЕНИЕ
Горизонтальное ска...
Альтернативные» се...
Глава 6. HUMMINBIR...
10.1.2.6 Другие фу...
Отзывы о книге Сет...
ГЛАВА 1. ОБЩИЙ ОБ...
8.4. Управление пр...
4.10 УПРАЖНЕНИЯ
6. Программные про...
Администра...
Глава 5. Что такое...
Почему САПР не "эл...
Производный атрибут
3.2.2. Сетевое обо...
Компактность и эфф...
Удобство использов...
4.9 ВЫВОДЫ
Степень связи
Мини-чат
Вам необходимо залогиниться.

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