Все о моделировании в Компас-3D LT
   Главная Статьи Файлы Форум Ссылки Категории новостей
Октябрь 23 2018 02:18:08   
Навигация
Главная
Статьи
Файлы
FAQ
Форум
Ссылки
Категории новостей
Обратная связь
Фото галерея
Поиск
Разное
Карта Сайта
Популярные статьи
Что необходимо ... 65535
4.12.1 Професси... 21842
Примеры, синони... 21022
Учимся удалять!... 19870
FAST (методика ... 18633
Просмотр готовы... 18468
Декартовы коорд... 16734
Просмотр готовы... 15282
Работа с инстру... 11567
Что такое САПР 10973
Сейчас на сайте
Гостей: 2
На сайте нет зарегистрированных пользователей

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

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

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

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

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

Пароль



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

Забыли пароль?
Запросите новый здесь.
Случайные статьи
7.2.3 Посылка сигн...
Глава 4. Основные ...
По законам джунглей
Автомобильные приб...
Протоколы
6.8 УПРАЖНЕНИЯ
Меры предосторожности
Правое и левое
Бенчмаркинг процесса.
4.12.3.1 Поколения...
5.4 Информационно...
Комплект Pocket Na...
Группа 3 — програм...
5.12.2 Открытие по...
Управление програм...
3.3 МЕХАНИЗМ ПОИСК...
10.4.2 Анализ потоков
Структура книги
Технология совмест...
Анализ программног...
Признак каскадного...
Связь с ци...
Принцип 1. Как мож...
9.2.2 "Сборщик" ст...
содержание - сетев...
Анализ результатов...
Глава 2. GARMIN ST...
5.6 CLOSЕ
4.7 ВЫДЕЛЕНИЕ ДИС...
Правила для атрибутов
Функциональный пример
Часть 6. Автомобил...
содержание - сетев...
Эталонная модель в...
5.12 КАНАЛЫ
2.4.1 Кодирование ...
Независимость данных
Поворотный экран
Декартовы координа...
Метод доступа в се...
Мини-чат
Вам необходимо залогиниться.

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