Помимо унаследованных от каскадной модели недостатков, методология ASAP имеет собственные отрицательные стороны:

Как мы видим, сама дорожная карта является очень абстрактной. Она в самых общих чертах описывает назначение каждой фазы. При этом в описание первых трех фаз, на которых производится планирование, проектирование и реализация самого главного в процессе внедрения ERP системы - архитектурного решения, входит раздел "Интеграция", который не дает совершенно никакого представления о том, как, что и с чем должно интегрироваться и как это должно происходить.

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

Компания SAP AG, видимо прикрывая эти белые пятна, в подавляющем большинстве разделов дорожной карты, связанных с методологией процесса внедрения, добавила идентичные подразделы следующего содержания:

"… Дополнительная информация

Используйте ASAP с Отдельными Методологиями управления проектами

ASAP процедуры управления проектами предназначены для поддержки только основных групп процессов управления проектами: инициация, планирование, выполнение, контроль и закрытие. Для дополнительных акселераторов и процессов, усильте методологию управления проектом клиента, SAP консультанта или SAP сервис партнера. (Это может быть специфическое календарное планирование, управление проблемами, регистрация опыта проекта или процесс контроля изменений, например.) Такие дополнительные материалы могут быть объединены в отдельную, специфичную для данного проекта дорожную карту…"

Таким образом, методология ASAP не столько помогает клиенту в процессе внедрения ERP системы, сколько помогает компании SAP и ее партнерам получить дополнительные заказы на консалтинг и обучение.

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

Рассмотрим пример. Предположим, в процессе инициации проекта нам необходимо распределить роли между имеющимися членами команды проекта. Мы обращаемся к соответствующему разделу методологии ASAP для того, чтобы получить ответ на вопрос: как это сделать?

Мы раскрываем узел первой фазы "Подготовка проекта", спускаемся ниже к группе работ "Общее управление проектом", раскрываем работу "Инициация проекта" и переходим к задаче "Назначение людей на роли". Текстовое описание задачи выглядит следующим образом:

"… Назначение людей на Роли

Использование

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

Необходимо позаботиться о том, чтобы заполнить ролевые позиции наиболее талантливыми людьми в компании.

Процедура

1. Сопоставьте ресурсы компании и консультантов ролям.

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

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

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

2. Назначьте ресурсы на роли.

Результат

· Организационный план команды проекта с назначенными людьми

· Краткое описание ответственности и навыков, необходимых для каждой роли …"

При этом на вкладках мы видим, что в результате выполнения этой задачи акселераторы не создаются. В выполнении этой задачи участвуют четыре роли:

· Член команды проектного офиса;

· Менеджер по интеграции;

· Менеджер проекта;

· Внутренний аудитор (представитель клиента).

Во-первых, в первом же абзаце мы встречаем упоминание некой "предыдущей задачи". Возникает вопрос, что считать предыдущей задачей: предыдущий "лист" дерева, узел предыдущего уровня, или задача, предшествующая по времени? Здесь мы сталкиваемся с первым существенным методологическим недостатком:

· отсутствие формально обозначенных связей и последовательностей выполнения между задачами, работами, группами работ и областями знаний внедрения;

Во-вторых, совершенно не понятно, каким образом выделенные в данной задаче четыре роли должны участвовать в получении двух результатов, которые, по своей сути, являются акселераторами. Не ясно главное - то, что рассматривалось в главе 1: Кто Что создает и Как взаимодействует? Следствием этого являются еще два взаимосвязанных существенных методологических недостатка ASAP:

· отсутствие формально обозначенных связей между задачами, их входами и выходами (акселераторами);

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

2.3 Возможные пути решения современных проблем внедрения ERP систем с использованием методологии ASAP на отечественных предприятиях

Концептуальный пересмотр методологии

Размещено на http://www.allbest.ru/

Рисунок 24. Концептуальный пересмотр методологии AcceleratedSAP на Карте процессов.

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

Рассмотрим вариант инкрементной модели пересмотра. Действительно, рассматривая рекомендации по использованию инкрементной модели, изложенные в главе 1, необходимо отметить, что внедрение ERP систем "за один проход" действительно связана с высокой степенью риска.

Однако вызывает сомнение тезис о том, что при внедрении ERP системы большинство требований можно сформулировать заранее, но их появление ожидается через определенный период времени. Внедрение ERP системы, как правило, связано с кардинальными изменениями во всей системе управления компанией или даже самого бизнеса. Часто такое внедрение сопровождается реинжинирингом бизнес процессов и переходом от второго уровня зрелости (Capability Maturity Model, CMM) к третьему уровню, с которым связана соответствующая организационно-культурная ломка в компании. В связи с этим, с высокой долей вероятности можно предполагать, что при внедрении ERP системы на отечественном предприятии требования к ней будут собираться и пересматриваться довольно продолжительное время, возможно на всем протяжении проекта.

Другим существенным фактором, мешающим выбрать инкрементную модель для концептуального пересмотра методологии ASAP, является ориентированность этой модели на построение системы из отдельных, четко разграниченных модулей, связывающихся между собой через строго определенные интерфейсы. Дело в том, что архитектура ERP систем компании SAP по своей сути не является модульной. Да, компанией SAP декларируется концептуальное деление ее ERP решений на модули, например логистическую цепочку MM, PP, SD или модули управленческого финансового учета (FI, CO). Но в действительности эти модули настолько переплетены, как общими данными (единая реляционная структура, ниже третьей нормальной формы), так и недокументированными процедурами взаимных вызовов, что внедрение "части" ERP системы SAP, состоящей из ограниченного набора модулей, как правило, ведет к неустойчивой работе системы и неконтролируемому ограничению функциональности внедренных модулей.

Гораздо больше для внедрения ERP систем компании SAP подходит спиральная модель. Очень важно, что эта модель позволяет управлять процессами разработки, связанными с высокой степенью риска. Такая степень риска (как по вероятности наступления, так и по величине последствий, цене риска) очень характерна для процессов внедрения ERP систем. Процент неудачных внедрений ERP систем во всем мире по-прежнему высок, а его следствием нередко становится разорение компании.

В процессе внедрения ERP систем нередко применяются и новые технологии, и существует необходимость тестирования базовых концепций. Вопреки заявлениям производителей готовых "коробочных" ERP систем, их решения не снижают риск неудачи внедрения, лишь потому, что решение уже готово, его осталось всего лишь установить и настроить. ERP системы внедряются не в "безвоздушное пространство", а в уже имеющуюся у предприятия информационную среду, в которой могут встретиться известные проблемы "наследуемых систем". Кроме того, импортные ERP решения часто требуют изощренной изобретательности членов команды внедрения, направленной на устранение несоответствия стандартной функциональности этих решений отечественным реалиям бизнеса и действующего законодательства. На практике, скорее всего, не удастся встретить отечественное внедрение ERP системы SAP, которое не сопровождалось бы широкомасштабным ABAP или Java программированием. Как правило, объемы такого программирования сводят к нулю все преимущества "коробочных" ERP решений и при интеграции "в слепую" в их недокументированную архитектуру существенно повышают риск неудачного внедрения.

Еще один фактор, склоняющий чашу весов в сторону спиральной модели - неуверенность пользователей в своих потребностях. Требования к ERP системам очень сложны и трудноопределимы. Часто для их определения и формализации нужны серьезные исследования.

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

Проекты внедрения ERP систем, как правило, велики и долгосрочны. Финансирование таких проектов обычно производится частями, которые могут быть согласованы по времени с "витками спирали".

Как отмечалось ранее, риск неудачного внедрения очень высок, поэтому не может быть уверенности в удачном завершении проекта.

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

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

Усиление методологии инструментарием

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

Для устранения данных существенных методологических недостатков необходим новый инструментарий, который можно было бы использовать в качестве альтернативы дорожной карте ASAP при внедрении ERP систем компании SAP на отечественных предприятиях. При этом данный инструмент должен как минимум:

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

· формально обозначить связи между задачами, их входами и выходами (акселераторами);

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

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

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

Перенос производился с использованием CASE-инструментария Rational Method Composer 7.2.0 компании IBM (США), предназначенного для разработки и модификации методологий, являющихся частными экземплярами единой методологической платформы Rational Unified Process (RUP), изучаемой в курсе eMBI402 "Основы бизнес моделирования". В процессе переноса производилось моделирование в нотации UML 2.0 (с допустимыми расширениями формального синтаксиса) средствами activity диаграмм. При этом в качестве концепции моделирования была взята архитектура UMA, заложенная в основу новейшей версии методологической платформы RUP. Концепция и нотация моделирования, инструментальное средство Rational Method Composer 7.2.0 и результат экспериментального переноса методологии ASAP на методологическую платформу RUP описаны в главе 3.

Вывод

Предусмотрены следующие элементы наполнения методов:

· Продукт работы (Рабочий продукт, Work Product)

· Роль (Role)

· Задача (Task)

· Категории и Представления (Categories and Views)

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

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

Предусмотрены следующие типы продуктов работы:

· Артефакт

· Конечный продукт

· Исход

Артефакты - это материальные продукты работы, которые создаются, изменяются и используются в ходе выполнения задач. Одни артефакты могут состоять из других. Например, артефакт модели состоит из элементов модели, которые также представляют собой артефакты. Артефакты могут применяться для определения многоразовых ресурсов. Роли пользуют артефакты для выполнения задач и создают артефакты в результате их выполнения.

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

Примеры артефактов:

· Спецификация варианта в Microsoft Word

· Модель проекта в Rational Software Architect.

· План проекта в Microsoft Project.

· Дефект в Rational Clear Quest.

· База данных требований к проекту в Rational RequisitePro.

Конечный продукт - это продукт работы, который содержит описания и определения других продуктов работы и применяется для их упаковки и поставки внутренним или внешним заказчикам. Таким образом, конечные продукты представляют собой инструменты группировки продуктов работы.

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

Исход - это совокупность нематериальных продуктов работы, возникших вследствие выполнения каких-либо действий, либо некое наступившее состояние. Примером исхода может служить установленный сервер или оптимизированная сеть. Хотя исходы зачастую документируются неформально (например, в заметках или стенограммах), они могут применяться для описания продуктов работы, которые не определены формально. Главное отличие исходов от артефактов заключается в том, что исходы не рассматриваются в качестве ресурсов, допускающих многократное использование. К исходам нельзя привязывать шаблоны или примеры, и их нельзя повторно использовать в качестве ресурсов в других проектах.

Роль - это элемент метода, представляющий собой совокупность взаимосвязанных навыков, знаний и сфер ответственности. Роли применяются для управления ответственностью за выполнение задач и соответствующие продукты работы. Как правило, роли назначаются отдельным сотрудникам или группам совместно работающих сотрудников. Необходимо учитывать, что роли - это не сотрудники и не должности. Это правила взаимодействия сотрудников в рамках проекта и совокупности сфер ответственности сотрудников. Каждый член проектной команды может выступать в разных ролях. Руководитель проекта назначает роли сотрудникам при подборе персонала для выполнения проекта.

Задача представляет собой минимальный квант работы, который назначается роли и в результате выполнения которого получается осмысленный результат. Задача представляет собой единицу работы. Для любой задачи указаны роли, которым разрешено ее выполнять. Обычно задача охватывает объем работы, выполняемый в течение промежутка времени от нескольких часов до нескольких дней. Как правило, единица работы влияет только на один или небольшое число продуктов работы. Задачи редко используются для планирования и контроля хода выполнения проекта - как правило, для этих целей лучше подходят операции, поскольку задачи представляю собой слишком мелкие объекты. У задачи есть четкое назначение, которое обычно выражается в создании или изменении определенных продуктов работы, например моделей, классов или планов. Каждая роль, участвующая в выполнении задачи, получает строго определенную цель. Задача содержит полные пошаговые инструкции по выполнению всех действий, необходимых для достижения этой цели. Эти инструкции не зависят от того, на каком этапе жизненного цикла выполняется задача. Поэтому в описании задачи не указано конкретное время выполнения действий. Вместо этого перечислены все действия, которые должны быть выполнены в рамках жизненного цикла для достижения цели задачи. Когда задача применяется в конкретном процессе, специальный объект, называемый дескриптором задачи, содержит информацию о том, какие элементы задачи необходимо выполнить в данный момент времени. Предполагается, что в ходе процесса задача будет выполняться многократно, однако всегда немного по-разному. Разница может выражаться в том, каким шагам или аспектам описания задачи будет уделяться основное внимание, в ролях, в наборе выходных и выходных объектов и в других характеристиках.

Категории. Категории представляют собой различные способы структурирования элементов наполнения метода. Помимо стандартных категорий, предусмотренных в UMA для большинства типов элементов наполнения, можно создавать пользовательские категории для выполнения следующих задач:

· Распределение наполнения по категориям, определенным пользователем;

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

Имеются следующие виды категорий:

· Дисциплина. Дисциплиной называется совокупность задач, относящихся к одной "области внимания" в рамках всего проекта. Группировка задач по дисциплинам применяется в основном для подчеркивания отличий данной архитектуры от традиционной водопадной архитектуры. Хотя зачастую задачи, относящиеся к разным дисциплинам, могут выполняться одновременно (например, определенные задачи управления требованиями могут выполняться вместе с задачами анализа и проектирования), дисциплины представляют собой важный механизм структурирования наполнения проекта, упрощающий его понимание. Еще одна причина, по которой задачи могут быть объединены в одну дисциплину, заключается в том, что эти задачи представляют собой элементы решения задачи более высокого уровня или выполнения различных этапов одной и той же работы. В каждой дисциплине описан стандартный способ решения ее основной задачи. Такие стандартные способы называются стандартными потоками операций и описываются с помощью шаблонов возможностей, в которых указано, как лучше всего упорядочить выполнение задач дисциплины. Стандартные потоки операций часто применяются для обучения и инструктирования разработчиков. Подобно другим потокам операций, стандартный поток операций дисциплины представляет собой ориентированную структуру процесса или диаграмму операций, позволяющую получить ожидаемый результат. Ориентированность структуры ограничена в том смысле, что в потоках операций дисциплины невозможно учесть нюансы выполнения реальных проектов, и поэтому в них нельзя отразить то, насколько обязательны или нет те или иные операции, и сколько итераций потребуется для выполнения конкретного проекта. Тем не менее, дисциплины значительно упрощают проект для понимания за счет разбиения процесса на несколько составляющих.

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

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

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

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

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

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

Предусмотрены следующие ключевые элементы процессов:

· Операция

· Шаблон возможностей

· Процесс поставки

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

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

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

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

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

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

· Для непосредственного выполнения блоков операций в проектах, основанных не на структурированном процессе, а на слабо связанных фрагментах операций (например, в модели Agile).

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

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

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

Как показано на рисунке 27, множества Наполнений Методов и Процессов могут пересекаться. Общими элементами этих множеств являются Указания.

Указание - это абстрактная концепция, применяемая для описания всех видов наполнения, основная цель которого заключается в описании и иллюстрировании элементов модели, включая роли, задачи, продукты работы, операции и процессы.

Указания могут принимать различные формы:

· Контрольный список. В контрольном списке перечислены элементы, нуждающиеся в завершении или проверке. Контрольные списки часто применяются при выполнении критического анализа и инспектировании. В UMA у элемента наполнения может быть только один Контрольный список. Контрольные списки применяются в различных контекстах: они помогают принимать решения о том, что требуется сделать, упрощают выполнение этих решений, помогают оценить качество работы и понять, как конкретный продукт работы связан с остальным процессом. Как правило, к каждому продукту работы привязан контрольный список со сведениями о том, как разрабатывать, оценивать и использовать этот продукт.

· Концепция - это ключевые идеи или принципы, на которых основан метод. Обычно концепции описаны на более высоком уровне, чем Рекомендации, и могут распространяться на несколько продуктов работы, задач и операций. В контексте разработки программного обеспечения основные Концепции, например риски или тестирование, вводятся на разных уровнях процесса и привязаны к ближайшим элементам наполнения. Некоторые концепции, в которых описаны различные задачи и продукты работы определенных дисциплин, привязаны к соответствующим дисциплинам.

· Пример. Представляет собой типичный незавершенный образец элементов наполнения. Чаще всего применяются образцы продуктов работы. Пример продукта работы - это хорошее дополнение к указаниям по его применению. Цель примеров заключается в практической демонстрации применения продуктов работы.

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

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

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

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

· Путеводитель. Указания этого типа содержат краткую информацию о процессе, как правило, с определенного ракурса. Путеводитель содержит важную документацию об определенной операции или определенном процессе. Зачастую самый простой способ объяснения сути сложной операции, например процесса, заключается в пошаговом описании типичного сценария выполнения этой операции. Помимо наглядного описания процессов, путеводители содержат информацию о том, как операции и задачи связаны между собой во времени. Путеводители также применяются для описания особенностей распределения тех или иных объектов или концепций в масштабах всего процесса и служат своеобразным фильтром для поиска определенной информации по процессу.

· Справочные материалы. К этому типу указаний относятся все указания, не входящие в другие категории.

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

· Определение термина. В руководствах этого типа изложены понятия, из которых формируется глоссарий.

· Памятка по инструменту. Инструкции по применению определенных инструментов для создания продуктов работы, как в контексте, так и вне контекста задачи или операции. В задачах, шагах и соответствующих указаниях можно найти общую справочную информацию. Памятки по инструментам представляют собой особый вид указаний, представляющий собой инструкции по выполнению различных процедур с помощью конкретных программных средств. Памятки по инструментам привязывают выполнение задач к конкретным инструментам, включая Rational Rose, Rational RequisitePro, Rational ClearCase, Rational ClearQuest и Rational Suite TestStudio. В памятках практически полностью инкапсулированы особенности конкретных инструментов, и это позволяет сделать задачи полностью независимыми от конкретной среды разработки. Предусмотрена возможность адаптации памяток к новым и нестандартным инструментам.