Руководство по процессу разработки в IAS

0 Содержание

Руководство по процессу разработки в IAS. 1

0 Содержание. 1

1 Цель и применение модели процесса разработки в IAS. 1

1.1 V-модель. 2

1.2 Цели Модели Процесса разработки в IAS. 2

1.3 Выполнение правил QA.. 2

2 Введение в модель процесса. 2

2.1 Организационная Структура. 4

2.2 Структура и содержание модели процесса разработки. 4

2.2.1 Действия и Продукты.. 4

2.2.2 Состояния продукта. 6

2.3 Обязанности. 6

3 Литература. 8

1 Цель и применение модели процесса разработки в IAS

Модель процесса разработки в IAS определяет универсальную и обязательную процедуру действий и результатов для студенческих проектов и тезисов. В этой определяются 5 классов модели процесса, которые описывают отдельные правила для различных предметных областей. Эти пять классов модели процесса следующие:

· Модель для разработки программного обеспечения

· Модель для разработки аппаратных средств

· Модель для развития системы

· Модель для концептуальных проектов

· Открытая модель

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

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

Фактическое создание тезисов сопровождается действиями, которые имеют дело с проверкой качества (QA), управлением конфигурацией (СМ) и техническим руководством проектом (PM).

1.1 V-модель

Развитие модели процесса разработки IAS было основано на модели V [3]. Модель V - общая модель процесса, которая не предписывает определенную организационную структуру или последовательность времени. Все же все необходимые действия и продукты, так же как их взаимозависимости, для выполнения проекта были определены. Сначала модель V была исследована, с целью приспособления к специальным потребностям проектов, которые ведутся единственным человеком, в то время как организационная структура IAS была учтена. Чтобы определять последовательность времени проектного выполнения для тезисов, модель V была объединена с простой фазовой моделью.

1.2 Цели Модели Процесса разработки в IAS

Стандартизированный процесс разработки моделирует поддержку достижения следующих целей:

обучение студентов в областях:

технологии программного обеспечения;

руководство проектом и проектное выполнение;

взаимодействие внутри команды;

документирование.

улучшение и гарантия качества:

стандартизированная процедура - лучшая гарантия полных результатов;

предопределенные промежуточные отчеты учитывают требования на раннем этапе;

однородное содержание продукта упрощает удобочитаемость продуктов и выполнение испытательных тестов;

возможность многократного использования:

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

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

1.3 Выполнение правил QA

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

2 Введение в модель процесса

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

Модель процесса состоит из четырех подмоделей (Рисунок 2-1). Помимо подмодели выполнения проекта (PE), есть также подмодели проверки качества (QA), управления конфигурацией (СМ) и руководства проектом (PM). Задачи проверки качества охватывают определение требований к тестированию продукта. О результатах сообщают руководству проектом. Цель управления конфигурацией состоит в том, чтобы создать продукт, например, документ, который является уникально опознаваемым. Эта идентификация предусматривает систематический контроль изменений и обеспечивает целостность. Модель процесса разработки управляет взаимодействием между индивидуальными подмоделями, определяет распределение различных задач различным людям или командам.

Рисунок 2-1: Четыре подмодели PE, QA, СМ и PM

Подмодели руководство проектом (PM), управление конфигурацией (СМ) и проверка качества (QA), которые описывают сопровождающие действия в процессе разработки, являются одинаковыми для всех классов модели процесса. Напротив, подмодель выполнения проекта (PE) серьезно отличается для каждого класса модели процесса.

Для лучшего дифференцирования различным PE дали отдельные названия, а именно:

· разработка программного обеспечения (SWD) для модели проектов разработки программного обеспечения;

· развитие аппаратных средств (HWD) для модели проектов разработки аппаратных средств;

· разработка системы (SD) для модели проектов разработки системы;

· развитие концепции (CD) для модели концептуальных проектов.

Для класса модели процесса открытой модели никакое отдельное название не давалось.

2.1 Организационная Структура

Рисунок 2-2 показывает организационную структуру модели процесса разработки в IAS. Проект программного обеспечения (модель разработки программного обеспечения) использовался здесь как пример.

Рисунок 2-2: Организационная структура модели процесса разработки в IAS

Тезис или любой другой тип студенческой работы выполняются как проект. Четыре подмодели модели процесса встроены в организационную структуру IAS. Ради образования в области технологий программного обеспечения студент выполнит упражнения во всех четырех подмоделях. IAS поддержит студента в руководстве проектом (PM), управлении конфигурацией (СМ) и проверке качества (QA). В подмодели разработки программного обеспечения (SWD) студент полностью ответственен за полное выполнение своей задачи.

2.2 Структура и содержание модели процесса разработки

Основные элементы модели процесса - действия и продукты, которые выполняются и обрабатываются в течение процесса выполнения проекта.

2.2.1 Действия и Продукты

Деятельность - действие, которое может быть точно описано в ссылке на его результаты и выполнение. Действия могут состоять из ряда определенных “промежуточных действий”, если каждое из этих промежуточных действий имеет его собственные определенные промежуточные результаты.

Продукт является или обработанным объектом или результатом деятельности. Аналогично подразделению действий в промежуточных действиях, продукты могут также быть подразделены на “промежуточные результаты” (например, индивидуальные главы документа).

Деятельность может быть

- создание продукта,

- изменение состояния продукта

- изменение содержания продукта.

Эти основные элементы "деятельность" и "продукт" представлены специальными символами (см. Рисунок 2-3).

Рисунок 2-3: Символы для продуктов и деятельности

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

Каждый продукт должен иметь описание продукта, которое определяет содержание продукта. Описание продукта происходит согласно зафиксированному образцу, схеме продукта. Для документов схемы тезисов обеспечиваются в форме шаблонов документов Word.

2.2.2 Состояния продукта

В процессе обработки продукты проходят различные Продукты могут принимать следующие состояния:

"in progress"

Продукт обрабатывается. Он находится под контролем разработчика.

"submitted"

С точки зрения создателя продукт закончен и был сохранен с использованием управления конфигурацией. Для продукта выполняется тест проверки качества. Если продукт не будет принят QA, тогда он возвратится к состоянию "in progress", в противном случае он перейдет состояние "accepted". После "submitted" создатель может только выполнить модификации продукта, используя увеличение номера версии.

"accepted"

Продукт был проверен и выпущен QA и может только быть изменен только в пределах новой версии.

Возможные переходы между состояниями показаны на рисунке 2-4.

Рисунок 2-4: Состояния и возможные переходы между ними.

2.3 Обязанности

Рисунок 2-4 показывает обязанности при создании индивидуальных проектов в течение процесса разработки на примере проекта программного обеспечения.

Рисунок 2-4: Обязанности для индивидуальных продуктов

[1]	Bitsch, F. et al.: IAS-DE - Description of the Development Environment, Version 3.8, IAS, 2002.
[2]	Booch, G.; Rumbaugh, J. and Jacobson, I.: The Unified Modeling Language, Addison Wesley, 1999.
[3]	Bundesamt für Wehrtechnik und Beschaffung: Development Standard for IT System of the Federal Republic of Germany, Lifecycle Process Model, June97.
[4]	Cockburn, A.: Structuring Use Cases with Goals, http://www.members.aol.com/acockburn/papers/usecases.htm, 1999.
[5]	Göhner, P.: Lecture Software Engineering for Real-Time Systems, IAS, Stuttgart, 2000.
[6]	Göhner, P.: Lecture Softwaretechnik II, IAS, Stuttgart, 2000.
[7]	Pressman R.-S.: Software-Engineering - A Practitioner's Approach, Third Edition, European Edition, McGraw-Hill Publishing Company, England, 1994.