1. Общие положения. 2 Цель методик - umotnas.ru o_O
Главная
Поиск по ключевым словам:
страница 1
Похожие работы
Название работы Кол-во страниц Размер
1. Общие положения. 2 1 Цель методик 1 225.9kb.
1. Общие положения. 1 Цель методик 1 82.26kb.
I. общие положения глава основные положения 8 4553.65kb.
Положение об ансамбле казачьей песни «Казачьи напевы» общие положения... 1 34.74kb.
1 Общие положения гипотезы устойчивого развития 3 14 2043.9kb.
Общие положения программа 1 274.23kb.
Об издательстве общие положения 1 55.89kb.
Общие положения Полное наименование оу 16 6399.1kb.
1. Паспорт программы. 2 Общие положения 5 1625.17kb.
Общие положения по учету основного производства 1 60.06kb.
Правила приема 2010 год Общие положения 1 164.33kb.
Примечания (в случае несоответствия): Тема анализируемого урока 1 83.39kb.
Викторина для любознательных: «Занимательная биология» 1 9.92kb.

1. Общие положения. 2 Цель методик - страница №1/1



Содержание:



1.Общие положения. 2

1.1.Цель методики. 2

1.2.Цель процесса 2

1.3.Место процесса в процессе организации. 2

1.4.Функции и рабочие продукты процесса 2

1.5.Входы процесса. 3

1.6.Выходы процесса. 3

1.7.Интерфейсы с другими процессами. 3

1.8.Данные о разработчиках методики. 4

2.Разработка требований заказчика. 4

2.1. Определение требований. 4

2.2.Разработка требований заказчика. 5

3.Разработка требований к продукту и его компонентам. 5

3.1.Разработка требований 5

3.2.Распределение требований между компонентами продукта. 6

3.3.Определение требований к интерфейсам. 6

4.Анализ и валидация требований. 7

4.1.Разработка концепции и сценариев валидации требований. 7

4.2.Анализ требований. 7

4.3.Анализ влияния рисков. 8

4.4.Валидация требований соответствующими методами. 8

5.Организация управления процессом. 8

5.1.Организационная политика. 8

5.2.Планирование процесса. 8

5.3.Обеспечение ресурсами. 9

5.4.Распределение ответственности. 9

5.5.Подготовка персонала. 9

5.6.Управление конфигурацией. 9

5.7.Определение и привлечение экспертов. 9

5.8.Управление и контроль процесса. 9

5.9.Измерение работ. 9

5.10.Обзор состояния работ менеджментом. 10

5.11.Сбор улучшающей информации. 10


1.Общие положения.

1.1.Цель методики.

Настоящая методика определяет порядок работы группы разработки программного обеспечения по выполнению организационного процесса «Разработка требований»
1.2.Цель процесса

Цель процесса «Разработка требований» - описать деятельность группы, разрабатывающей ПО, при разработке документов требований к программному продукту, т.е. формулирование и анализ требований заказчика, требований к продукту и его компонентам.


1.3.Место процесса в процессе организации.

Процесс «Разработка требований» входит в состав процессов, обеспечивающих разработку, изготовление и сопровождения продукта (Engineering Process Area).


1.4.Функции и рабочие продукты процесса

Процесс «Разработка требований» идентифицирует потребности заказчика и преобразовывает их в требования к программному продукту. Набор требований к продукту подвергается анализу на соответствие принимаемым решениям по составу и верхнеуровневому дизайну продукта. Требования к продукту и возникающие требования и ограничения, соответствующие принятому дизайну, могут преобразоваться в набор требований для компонент продукта. Набор требований к продукту и его компонентам описывает рабочие характеристики продукта, особенности его построения, требования к верификации, требования к интерфейсам и т.п.

Процесс «Разработка требований» включает следующие функции (применяется к следующим задачам):


  • Разработка Перечень требований заказчика;

  • Разработка требований к продукту и его компонентам;

  • Анализ и валидация требований.

Рабочими продуктами процесса «Разработка требований» являются:

  • Список требований заказчика;

  • Список ограничений заказчика по проведению верификации и валидации продукта;

  • Вторичные (derived) требования;

  • Требования к продукту;

  • Требования к компонентам продукта;

  • Листы распределения требований;

  • Ограничения дизайна;

  • Производные требования;

  • Требования к интерфейсам;

  • Логико-временные сценарии использования продукта;

  • Отчеты по недостаткам в требованиях;

  • Предлагаемые изменения требований для устранения дефектов;

  • Оценка рисков по отношению к требованиям;

  • Методы и результаты верификации требований.


1.5.Входы процесса.

Входными данными процесса являются:



  • Документация, описывающая потребности заказчика (документы заказчика, описывающие потребности и требования заказчика, протоколы технических встреч с заказчиком по вопросам выявления и согласования требований);

  • Документация предварительного дизайна продукта, включающая описание технологических, стоимостных, временных ограничений на разработку и изготовление продукта;

  • Документация, описывающая подход к тестированию (верификации и валидации) продукта и ограничения, связанные с тестированием.


1.6.Выходы процесса.

Выходными данными процесса являются:



  • Документы – спецификации требований к элементам конфигурации программного обеспечения, включая требования к интерфейсам и тестированию;

  • Таблицы прослеживаемости требований.


1.7.Интерфейсы с другими процессами.

Процесс «Разработка требований» имеет следующие внешние интерфейсы:



  • С процессом «Управление требованиями» по выдаче документов для сопровождения требований заказчика и требований к продукту, а также таблицы прослеживаемости требований;

  • С процессом «Техническая реализация» по выдаче предварительных списков требований заказчика, требований к продукту и его компонентам и по использованию информации о предварительном дизайне продукта, ограничениях дизайна продукта для уточнения требований к продукту и его компонентам и формулировки производных (derived) требований.

  • С процессом «Интеграция продукта» в части получения информации о требованиях к интерфейсам.

  • С процессом «Верификация» в части уточнения требований по верификации.

  • С процессом «Управление рисками» в части выдачи информации о требованиях к продукту и компонентам для определения и управления рисками, связанными с требованиями.

  • С процессом «Измерения и анализ» в части измерений работ по процессу;

  • С процессом «Конфигурационное управление» в части передачи рабочих продуктов процесса под конфигурационное управление;

  • С процессом «Качество процесса и продуктов» в части оценки качества требований и реализации процесса.

  • С процессом «Анализ и принятие решений» в части разрешения существующих противоречий требований.


1.8.Данные о разработчиках методики.
2.Разработка требований заказчика.

2.1. Определение требований.

2.1.1 Подгруппой разработки требований выполняется сбор документации содержащей базовые положения для определения требований заказчика. Потребности заказчиков, конечных пользователей, поставщиков, разработчиков и испытателей являются базой для определения требований заказчика. Потребности, ограничения, интерфейсы, операционные концепции, концепции продукта, выдвигаемые этими группами, анализируются, согласовываются, детализируются и перерабатываются для формирования набора требований заказчика. Ввиду возможной противоречивости потребностей и ограничений заказчиков, а также из-за необходимости четкой формулировки, однозначной интерпретации требований заказчика «определение требований» носит итерационный характер.

При разработке требований к программному обеспечению в ряде случаев можно использовать в качестве базового документа спецификацию функциональных требований к разрабатываемой системе (продукту) в целом. Пример – документ «User-Detailed Functional Requirements for the Russian Segment Simulation» в проекте RST, содержащий функциональные требования верхнего уровня к разрабатываемой системе.

2.1.2 Подгруппой разработки требований выполняется «выявления требований». Из-за особенностей технологического цикла разработки программного продукта могут возникать дополнительные требования, которые не сформулированы заказчиком в явном виде.

Для выявления требований применяются следующие методы:



  • Демонстрация технологии;

  • Рабочие группы по управлению интерфейсами;

  • Промежуточные рассмотрения проекта;

  • Анализ задач конечных пользователей, рассмотрение операционных сценариев и вопросов конечных пользователей;

  • Рассмотрение прототипов и моделей, а также аналогов;

  • Рассмотрение документации – стандартов и спецификаций;

  • Рассмотрение существующих продуктов, условий эксплуатации.

Указанные работы проводятся в виде технических встреч (совещаний) с заказчиками и совещаний групп технической реализации проекта, интеграции продукта, верификации. Принятые решения (выявленные требования) документируются в протоколах встреч.



2.2.Разработка требований заказчика.

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

Собранная информация от заказчика собирается в перечень требований заказчика, недостающая информация должна быть получена, в перечне требований заказчика должна быть учтена информация по требованиям и ограничениям к верификации и валидации программного продукта.

«Перечень требований заказчика» согласовывается с заказчиком.


3.Разработка требований к продукту и его компонентам.

3.1.Разработка требований

3.1.1 Перечень требований заказчика анализируется в соответствии с разрабатываемой операционной концепцией для получения более детальных требований – требований к продукту и его компонентам. Требования заказчика формулируются в технических терминах и детализируются. При этом используется предварительная информация группы технической реализации проекта об операционной концепции.

3.1.2 Формулируются требования, учитывающие ограничения, связанные с ограничениями дизайна (эти требования не вытекают непосредственно из требований заказчика). Указанные требования формулируются на основании информации группы технической реализации проекта.

3.1.3 Формулируются «вторичные» требования, связанные с фазами жизненного цикла продукта и его компонент, такими как производство, операции, транспортировка, утилизация. Эти требования формулируются на основании данных групп технической реализации проекта и конфигурационного контроля.

3.1.4 Разрабатывается предварительная таблица прослеживаемости требований более высокого уровня (требований заказчика) в требования к продукту и компонентам, в которой приведено соответствие требований заказчика наборам (группам) требований к продукту и компонентам.


3.2.Распределение требований между компонентами продукта.

3.2.1 Документ спецификации требований к продукту и его компонентам структурируется в соответствии с декомпозицией продукта на компоненты. Информация о функциональной декомпозиции продукта является частью предварительного дизайна и определяется группой технической реализации проекта. Принятое распределение требований к продукту и его компонентам должно учитывать требования к производительности программного продукта и ограничения дизайна.

3.2.2 В ряде случаев могут быть разработаны отдельные документы – спецификации требований к компонентам программного продукта. В этом случае требования более высокого уровня (требования к продукту), касающиеся производительности, должны быть повторены в требованиях к компонентам продукта в качестве вторичных требований.

3.2.3 Информация по распределению требований учитывается в таблицае прослеживаемости требований (таблица прослеживаемости требований обновляется в соответствии в распределением требований между компонентами продукта).


3.3.Определение требований к интерфейсам.
3.3.1 На основании архитектуры продукта идентифицируются интерфейсы (как внешние, так и внутренние). Должны быть учтены также интерфейсы, возникающие из-за принятого жизненного цикла продукта (интерфейсы с тестовым оборудованием и программным обеспечением, системами транспортировки, обеспечения и разработки).

3.3.2 Определяются требования к интерфейсам на основании требований заказчика и структурной декомпозиции программного продукта. При определении требований к интерфейсам используется предварительная информация группы интеграции о структуре продукта. Требования к интерфейсам определяются в виде описания входов-выходов и общих характеристик данных.



4.Анализ и валидация требований.

4.1.Разработка концепции и сценариев валидации требований.

4.1.1 На основании разработанной группой технической реализации проекта операционной концепции продукта разрабатываются сценарии для валидации требований к продукту и его компонентам. Валидация требований проводится для увеличения вероятности ожидаемой работы продукта в предполагаемом пользователем окружении. Сценарии должны включать операционные последовательности по установке, эксплуатации, обслуживанию, поддержке, утилизации продукта. Указанные сценарии разрабатываются на уровне детализации, соответствующем потребностям и ограничениям заказчика.

4.1.2 На основании данных заказчика определяется окружение, в котором продукт должен функционировать, включая существующие ограничения.


4.2.Анализ требований.

4.2.1 Анализ и требований выполняется по отношению к окружению, подразумеваемому пользователем продукта. Анализ производится для определения влияния подразумеваемой среды эксплуатации продукта на его способность выполнить требования заказчика. Цель анализа – выявление требований к концепции продукта, которая удовлетворяет потребности заказчика, и дальнейшее преобразование концепции в требования к продукту.

В соответствии с принятой операционной концепцией и сценариями проводится анализ требований к продукту на предмет определения их необходимости и достаточности с точки зрения выполнения задач продукта более высокого уровня (в принятой структуре продукта). На основании анализа уточняются требования к компонентам продукта более низкого уровня. При выявлении дополнительных требований к компонентам продукта должна быть установлена зависимость этих требований от требований более высокого уровня.

4.2.2 Проводится анализ требований на полноту, выполнимость и верифицируемость.

4.2.3 Проводится анализ для выявления ключевых требований к продукту, сильно влияющих на стоимость, график разработки продукта, функциональность продукта, риски, производительность.

4.2.4 Определяется перечень параметров продукта, базирующийся на предварительной концепции продукта и данных заказчика, который можно использовать для оценки эффективности продукта. Определяются параметры, определяющие технические характеристики продукта, которые могут быть прослежены в процессе разработки продукта (очевидный пример для программного обеспечения – объем используемых ресурсов компьютера – память, время выполнения).


4.3.Анализ влияния рисков.

4.3.1 Выполняется анализ баланса между потребностями и ограничениями заказчика. Результаты анализа используются для уменьшения стоимости разработки и производства продукта и рисков при разработкие продукта.

4.3.2 Производится оценка рисков по отношению к требованиям заказчика и требованием к продукту в соответствии с методикой процесса «Управление рисками».
4.4.Валидация требований соответствующими методами.

4.4.1 Валидация требований выполняется для того, чтобы на возможно ранней стадии удостовериться, что продукт, разработанный и произведенный в соответствии с данными требованиями, успешно пройдет конечную валидацию.

Для этого выполняется анализ требований для определения риска, что разработанный продукт не будет выполнять свои функции в подразумеваемой среде использования.

4.4.2 Выполняется проверка адекватности и полноты требований на прототипах продукта, моделях продукта, на ранних выпусках программного обеспечения, демонстрируемых заказчику. Замечания заказчика используются для уточнения и дополнения требований, выявления дополнительных потребностей заказчика, не сформулированных ранее.


5.Организация управления процессом.
5.1.Организационная политика.

Работы по реализации процесса «Разработка требований» осуществляет группа технической реализации проекта.

Состав группы и ее руководители утверждаются распоряжением Главного менеджера организации.

Группа подчиняется Главному менеджеру организации и обладает всеми полномочиями по выполнению работ, определенных настоящей методикой.


5.2.Планирование процесса.

Работа по реализации процесса осуществляется в соответствии с планами работ по проектам.


5.3.Обеспечение ресурсами.

Финансовое обеспечение работ осуществляется из средств выполняемых организацией проектов.

Затраты по выполнению процесса учитываются в планах выполнения проектов.

Работы по проекту обеспечиваются базами данных:



  • Измерений стандартных процессов;

  • Архива активов организации.


5.4.Распределение ответственности.

Группа технической реализации проекта несет ответственность за реализацию процесса.

Непосредственно процесс реализуется подгруппой разработки требований или специалистом, назначенным для разработки требований по данному проекту.
5.5.Подготовка персонала.

Подготовка персонала группы технической реализации проекта по реализуемому процессу осуществляется по плану группы, отвечающей за подготовку персонала организации.


5.6.Управление конфигурацией.

Перечень документов процесса, подлежащих конфигурационному контролю на уровне организации в целом, определяется разрабатывается и передается процессому «Конфигурационное управление».


5.7.Определение и привлечение экспертов.

Группа технической реализации проекта, реализующая данный процесс, контролируется менеджером проекта.


5.8.Управление и контроль процесса.

Управление и контроль процесса осуществляют руководители группы технической реализации проекта.

Основным методом управления и контроля являются оперативные совещания, проводящиеся на периодической основе с оформлением протоколов. Периодичность проведения совещаний определяется руководителями группы.
5.9.Измерение работ.

Группа технической реализации проекта ведет учет затрат по реализации процесса.

Работа по реализации процесса оценивается результатами обзоров.

Данные передаются процессу «Измерения и анализ».


5.10.Обзор состояния работ менеджментом.

Обзор состояния работ по процессу осуществляется менеджером проекта на периодической основе.


5.11.Сбор улучшающей информации.

В процессе выполнения работ группа технической реализации проекта обеспечивает сбор и хранение в базе данных информации о своей работе.



В состав информации входит:

  • Документы, разработанные группой;

  • Измерения работ, выполненных группой;

  • Недостатки в работе группы и в ее обеспечении и предложения по совершенствованию процесса.

Данные о совершенствовании процессов передаются группе SEPG.