ЧАСТЬ 1. МЕТОДОЛОГИЧЕСКИЕ ПОДХОДЫ К ОРГАНИЗАЦИИ ПРОЕКТИРОВАНИЯ И РАЗРАБОТКИ ПО

1.1. Проект и управление проектом

1.1.1. Основные определенияПонятие проекта и управления проектом (Project Management, РМ) в

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

До недавнего времени в отечественной практике термин “проект” использовался преимущественно в технической сфере, и с ним связывалось представление о совокупности документации по созданию каких-либо сооружений или зданий. Соответственно, разработка такой документации называлась проектированием. На Западе для обозначения этого процесса используется термин – дизайн (designing), а понятие “проект” (project) трактуется более широко.

Понятие "проект" в разных моделях и стандартах также трактуется с разных позиций. В процессной модели (ISO 9000, 10006) проект рассматривается как процесс, а в рамках "менеджерской", или организационно-деятельностной, модели (ICB IPMA – International Competence Baseline of International Project Management Association) проект определяется через термины "предприятие", "усилие" и "деятельность".

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

Источник Определение проектаIPMA Competence Base-line. Version 2.0. IPMA Editorial Committee. Bre-men: Eigenverlag, 1999. Р. 23.IPMA - International Project Management Asso-ciation

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

ISO/TR 10006: 1997 (E). Quality Management – Guidelines to quality in

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

1

project management Р. 1. конкретным требованиям, включая ограничения по времени, затратам и ресурсам.

Australian Institute for Project Management. Na-tional Competence Stan-dard for Project Manage-ment – Guidelines 1996. Р. 18.

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

British Standard BS 6079-1:2000. Project manage-ment — Part 1: Guide to Project management. Р. 2.

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

USA. A Guide to the Project Management Body of Knowledge. PMI Stan-dards Committee. 4 Edi-tion, 2000.. (PMBоK)

это временное предприятие (усилие), осуществляемое (предпринятое) для создания уникального продукта или услуги.

Таблица 1. Некоторые определения термина «проект»

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

1.1.2. Признаки проектаСформулируем основные признаки, выделяющие проектную

деятельность из других видов человеческой деятельности. Наличие цели. Всякая деятельность целенаправленна, однако цель

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

курсе "ПЗ в ИС": цель формируется в ментальном пространстве заказчика, отражается в ментальном пространстве исполнителя, а реализуется в пространстве задачи, которые представляют собою разные и, как правило, первоначально неприводимые знаковые системы. Для их приведения необходима взаимная перестройка структуры ментальных баз. Это – проблема менеджера проекта.

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

2

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

времени. У них есть более или менее четко выраженные начало и конец.Чаще всего временные рамки проекта определяются интересами

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

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

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

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

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

Например, конвейерное производство стандартной продукции не является проектом. Уникальность – создаваемые продукты или услуги существенно

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

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

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

3

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

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

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

выполнение работ", а "обеспечить выполнение работ в пределах заданных ограничений – в срок, в рамках выделенных средств, в соответствии с техническим заданием".

Основные ограничения проекта:1. время (срок окончания проекта);2. деньги (бюджет проекта);3. качество (соответствие ТЗ и/или пожеланиям потребителя);4. квалификация персонала;5. интенсивность труда.

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

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

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

Таким образом, можно дать определение управления проектом.

4

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

1.1.3. Пространство управления проектомДля реализации различных функций УП необходимы действия, которые

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

На рис. 1.1 по осям координат отложены те измерения, которые упоминаются в основных стандартах РМВоК [РМВоК], которые являются де-факто стандартами УП в России. Однако могут использоваться и другие оси (например, уровни моделирования, календарные периоды), а также другие структурирования по осям.

Рис. 1.1. Пространство управления проектом

1.1.4. Жизненный цикл проектаВ большинстве случаев ведущей координатной осью пространства УП

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

5

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

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

1. сбор исходных данных и анализ существующего состояния (предварительное обследование);

2. назначение руководителя проекта и формирование команды проекта, в первую очередь ее ключевых членов;

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

4. выявление потребности в изменениях (проекте); 5. определение проекта; 6. определение и сравнительная оценка альтернатив, принятие основных

концептуальных решений; 7. разработка предварительного плана проекта; 8. утверждение предварительного плана проекта и получение одобрения

на продолжение работ. Прокомментируем некоторые пункты этого списка.Пункты 3–5 объединяются как определение целей и результатов

проекта и рассматриваются как творческий процесс. Для поддержки их выполнения существуют индивидуальные и групповые методики: в индивидуальной работе – дискурсивные и логические методы (в этом

случае имеется опасность одностороннего рассмотрения направления поиска целей проекта);

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

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

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

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

6

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

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

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

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

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

проекта. Ввод в действие системы мотивации и стимулирования команды

(участников) проекта. Формальное и детальное планирование (на базе предварительного плана). Детальное проектирование и технические спецификации. Оперативное планирование работ. Установление системы информационного контроля за ходом работ. Организация и управление материально-техническим обеспечением работ. Выполнение работ, предусмотренных проектом (например, для проекта

разработки ПО – кодирование, тестирование, интеграция и др.). Руководство, координация работ, согласование темпов, мониторинг

прогресса, прогноз состояния, оперативный контроль и регулирование основных показателей проекта.

Решение возникающих проблем и задач. Подтверждение окончания работ и получение одобрения для работ

следующей стадии. Окончательно определяются ключевые точки (вехи) проекта,

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

7

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

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

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

заказчика); составление окончательного отчета, организация промежуточных отчетов

по проекту в виде архива; инвентаризация оборудования и, возможно, передача его для нового

применения; закрытие взаимоотношение с контрагентамии т.д.

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

Специфика организации ЖЦ для проекта по разработке ПО и средства ее инструментальной поддержки рассматриваются в последующих разделах курса.

1.1.5. Структура декомпозиции работ – основная модель проектаДля планирования и управления проектом необходимо определить и

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

8

Основой для структурирования проекта является структура декомпозиции работ (work breakdown structure, WBS).

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

Характеристики WBS: Описывает с необходимой точностью содержание работ по проекту. Определяет  весь объем работ по проекту. Формируется в виде иерархической структуры (проект декомпозируется

на пакеты/субпакеты и т.д. работ). Представляет объем работ по пакету как перечень работ, имеющих

измеримый или сравнимый результат. Каждая работа в WBS имеет объективный или измеримый результат. WBS должна быть согласована с деревом целей проекта. Правильно

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

Верхние уровни структурной декомпозиции работ проекта ориентированы на результаты или/и фазы жизненного цикла проекта, а нижние уровни отражают дальнейшую детализацию с ориентацией на работы проекта, вплоть до работ конкретного исполнителя. Для проектов средней сложности рекомендуется использовать до 6 уровней WBS: 3 верхние уровня для предоставления информации уровня заказчика, 3 нижние уровня для детализации информации уровня исполнителя.

WBS могут отличаться по принципам декомпозиции проекта: На самых ранних стадиях проекта, когда результаты еще четко не

сформулированы, строится структурная декомпозиция проекта в опоре на фазы жизненного цикла проекта (рис. 1.2).

В тех случаях, когда результаты проекта могут быть достаточно четко определены, декомпозиция проекта осуществляется с ориентацией на результаты проекта (рис. 1.3, 1.4). Результаты могут быть представлены объектно-конструктивными или функциональными частями проекта.

Соответствующие примеры для проекта разработки ПО (создание Web-сайта) представлены на рис. 1.2, 1.3, 1.4.

Уровень детализации WBS может также изменяться в процессе ЖЦ: для краткосрочных проектов на начальной стадии можно разработать всю

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

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

9

поздней стадии жизненного цикла проекта можно будет прописать их более детально.

Проект по созданию WEB-сайта

Создание дизайна

Аппаратное обеспечение

Программное обеспечение

Коммуни-кации

Интегра-ция

Логистика

Методы

Художники

Дизайн

Программы

Выбор оборудования

Определение архитектуры

Приобретение, тестирование

Подбор персонала

Проектирование

Тестирование

Прототипи- рование

Выбор провайдера

Определение сетевой конфигурации Система безопасности на уровне сети

Размещение ПО на аппаратном обеспечении

Тестирование ПО, внешней сети, системной производительности

Обработка заказа

Продажа

Поддержка пользователей

Авторизация средств оплаты

Рис. 1.2. Верхний уровень WBS по PMI (PMI Practice Standard for WBS).

Проект по созданию WEB-сайта

Система администрирования

Система шаблонов оформления

Система взаимодействия с посетителями

Система хранения данных

Управление содержанием и структурой

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

Управление шаблонами

Реализация ограничения доступа

Система опросов

Система протоколирования

Рис. 1.3. Верхний уровень WBS (учтен логический уровень) Проект по созданию WEB-сайта

Клиентская часть Система хранения данных

Дизайн Обработка вызовов, приходящих с интерфейса Выдача интерфейса пользователю

Запросы к БД

Серверная часть

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

Структура таблиц

10

Рис. 1.4. Верхний уровень WBS (учтен аппаратный уровень)Для оценки необходимого и достаточного уровня детализации WBS?

существуют специальные методики, например [Вопросник]: Есть ли необходимость в повышении точности оценки стоимостных

данных и длительности по пакету работ? Для пакета работ определен более чем один ответственный? Для

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

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

Есть ли необходимость в раздельном определении стоимости процессов или результатов, описанных в данном пакете работ?

Есть ли зависимость между частью работ внутри пакета работ и другими внешними пакетами?

Наблюдаются ли существенные перерывы в выполнении работ в рамках пакета?

Меняются ли требования к ресурсам в течение времени в рамках пакета работ?

Различаются ли исходные условия для работ внутри пакета работ? Существуют ли четкие, объективные критерии измерения выполнения для

пакета работ? Существуют ли утвержденные критерии, применяемые для оценки

завершения работ в целом по пакету? Существуют ли специфические риски, связанные с частью пакета работ и

требующие дальнейшей детализации пакета для выделения этих рисков? Может ли для части пакета работ отдельно пересчитываться расписание? Содержит ли пакет работ понятную и полную информацию с точки зрения

Проектировщика (планировщика), Исполнителя и Заказчика?

1.1.6. Разработка ПО как проектРассмотрим специфику разработки ПО как проектной деятельности.

Существуют объективные трудности целеполагания и оценки достижения цели

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

11

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

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

Рассмотрим примеры ценностей, создаваемых в ходе проекта по разработке ПО [Кулямин].

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

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

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

Результат разработки ПО не имеет непосредственного материального выражения

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

12

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

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

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

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

переход от проекта к продукту почти полностью автоматизирован — требуется лишь скомпилировать код и развернуть систему в том окружении, где она будет работать;

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

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

Принципиально неустранимая системная сложность технологической среды решения прикладных задач программирования. Ф. Брукс в 1975 г.)выделил следующие факторы системной сложности:

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

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

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

С развитием ИТ этот список расширился:

13

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

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

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

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

разрабатывается ППП.Внедрение ППП, как правило, связано со значительным изменением в

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

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

серьезным ошибкам и необходимости переделывания большой части работы. Актуален закон Мерфи: “Для определения времени, необходимого для выполнения работ, берется время исполнения, умножается на два и увеличивается единица измерения времени». Общеизвестная также статистика неудачно завершенных проектов.

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

первый уровень - общий план проекта, определяющий ЖЦ проекта с фазами, итерациями, и основными вехами

второй уровень - план каждой итерации, позволяющий парировать вновь возникающие неопределенности;

и т.д.Этому делению соответствуют разные декомпозиции WBS:

по базовому принципу декомпозиции бизнес-процесса и, соответственно, базовому структурированию информации, поддерживающей бизнес.

14

функциональные (организационно-функциональные) модели потоковые модели; структурные модели; объектные модели.

по уникальность / тиражируемости проектируемого ПО каноническое проектирование типовое проектирование

по логической последовательности работ в ЖЦ каскадная (водопадная – waterfall), инкрементальная (эволюционная), спиральная.

Типичные практики организации работ в ЖЦ, построенные путем детализации указанных классификаций, образуют методологии описания ЖЦ разработки ПО (см. раздел 1.3.1).

1.2. Архитектура проекта

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

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

Бизнес (предпринимательство) – самостоятельная, осуществляемая на свой риск деятельность, направленная на систематическое получение прибыли от пользования имуществом, продажи товаров, выполнения работ или оказания услуг лицами, зарегистрированными в этом качестве в установленном законом порядке [wikipedia/Бизнес].

Бизнес-процесс – это последовательность взаимосвязанных активностей или задач, которые приводят к созданию определенного продукта или услуги для потребителей. [wikipedia/Бизнес-процесс].

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

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

растет роль информационных технологий в эффективности традиционных бизнесов;

появился новый тип бизнеса – электронный, полностью основанный на информационных технологиях.

По данным [Данилин, Слюсаренко], крупная организация эксплуатирует в среднем около 40 критически важных прикладных систем, а служба ИТ крупного банка поддерживает работу около 300 различных прикладных систем. Наличие нескольких сотен прикладных систем – скорее правило, чем исключение для органов власти регионального уровня.

15

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

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

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

только со стороны бизнеса или только со стороны информационных технологий неэффективно или даже невозможно. Во многом с такими "односторонними", внесистемными попытками связано увеличение количества неудач в проектах, связанных с внедрением информационных систем. По оценкам различных консалтинговых компаний, примерно 50% ИТ-проектов в различных отраслях заканчиваются не так, как запланировано, а в государственном секторе этот процент достигает 70% [Данилин, Слюсаренко].

Для системного решения поставленных задач, т.е. для объединения и синхронизации функциональных и бизнес-потребностей организаций с возможностями информационных технологий в условиях их экспоненциальной сложности была предложена [Захман] концепция Архитектуры предприятия, которая включает в себя такие аспекты, как Бизнес-архитектура, Архитектура информации, Архитектура прикладных систем и Технологическая архитектура.

1.2.2. Определения архитектуры"Архитектурный взгляд" на системы (как ИТ-системы, так и бизнес-

системы) определен в стандарте ANSI/IEEE 1471-2000 как "фундаментальная организация системы, состоящая из совокупности компонент, их связей между собой и внешней средой, и принципов, которыми руководствуются при их создании и развитии" [IEEE 1471]. Этот стандарт определяет такие абстрактные элементы архитектуры, как представления, системы, среды, обоснования, заинтересованные стороны и т.д. в соответствии со схемой, показанной на рис. 1.5.

16

Рис. 1.5. Рамочная модель разработки архитектуры по IEEE 1471

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

по системному уровню описания; по учету динамики развития.

Так, по системному уровню описания можно выделить: (1) архитектуру предприятия в целом, (2) архитектуру уровня отдельных проектов или семейства продуктов, (3) архитектуру отдельной прикладной системы.

Архитектура предприятия (1) определяет общую структуру и функции бизнеса и ИТ-систем в рамках организации в целом (включая партнеров и другие организации, формирующие так называемое "расширенное предприятие"). и обеспечивает общую рамочную модель (framework), стандарты и руководства для архитектуры уровня отдельных проектов (2).

Архитектура уровня отдельных проектов (2) определяет структуру и функции бизнеса и ИТ-систем на уровне проектов и программ (совокупностей проектов), но не изолированно друг от друга, а в контексте всей организации в целом, т.е. в рамках (1).

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

17

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

Аспект динамики, содержащийся в понятии архитектуры, отражается в двух параллельных определениях, данных аналитической компанией Gartner. В соответствии с [Gartner], архитектура – это:1. общий план или концепция, используемая для создания системы, такой

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

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

Термин "ИТ-архитектура" может означать множество близких по смыслу, но, тем не менее, различающихся понятий. В литературе и Интернет-источниках представлено большое количество различных определений, которые также можно разделить на (1) статические и (2) процессные, например:

(1) ИТ-архитектура – это фундаментальная организация ИТ-систем, воплощенная в компонентах, их взаимоотношениях и принципах управления системами [NITTA];

(2) ИТ-архитектура – это изучение, проектирование, разработка, развертывание, поддержка и управление информационных систем на основе компьютеров, в частности, программных приложений и компьютерной инфораструктуры [ITAA]

Выделим основные содержательные характеристики обсуждаемых понятий [Данилин, Слюсаренко].

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

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

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

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

18

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

В делом можно предложить следующее соотношение:Архитектура предприятия (корпоративная архитектура) =

= бизнес-архитектура ++ корпоративная информационно-технологичеcкая архитектура

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

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

числе бизнеса и ИТ-системы, можно и нужно рассматривать как проект и, следовательно, определять для нее пространство управления проектом. Применительно к архитектуре предприятия это пространство формируется тремя основными осями: перспектива (perspective) = уровень абстракции; представление (view) =предметная область = домен архитектуры; динамика развития.

В свою очередь, каждая из осей имеет свое структурирование. Так, для описания оси перспектив параллельно используются несколько

структур, например:(1) абстракция руководства

1.1. уровень контекста – ориентирован на бизнес-руководство;1.2. концептуальный уровень или "Видение Общих Требований" – ориентирован на "владельцев" бизнес-процессов;1.3. логический уровень – ориентирован на архитекторов и проектировщиков систем;1.4. физический уровень – ориентирован на проектировщиков и разработчиков систем;1.5 уровень реализации – ориентирован на персонал, эксплуатирующий систему.

(2) абстракции проектирования2.1. уровень концептуального проектирования2.2. уровень логического проектирования2.3. уровень физического проектирования.

(3) абстракции организационного уровня3.1. архитектура предприятия – масштаб предприятия в целом, высокий уровень абстракции, корпоративные знания;3.2. архитектура отдельных решений и систем – технологии предприятия в целом, планирование систем, структура решений, архитектура программных систем;

19

3.3. дизайн конкретного решения –.технологии в узком понимании, их детальное описание, дизайн программных систем, архитектура отдельных компонент.

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

ее ключевых бизнес-процессов; архитектура информации – определяет, какие информация необходима

для поддержания бизнес-процессов (например, модель данных), а также для обеспечения стабильности и возможности долговременного использования этих данных в прикладных системах;

архитектура прикладных систем – определяет, какие приложения используются и должны использоваться для управления данными и поддержки бизнес-функций (например, модели приложений);

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

Иногда целесообразно выделять дополнительные области, например: архитектура интеграции – определяет инфраструктуру для предоставления

пользователям интегрированных услуг по принципу "единого окна"; архитектура общих сервисов – электронная почта, каталоги, общие

механизмы безопасности; сетевая архитектура – определяет описания, правила, стандарты, которые

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

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

доменов архитектуры предприятия, укрупненно представлено в табл. 1.1.

Таблица 1.1Наименование домена

Задаваемые концепты

Бизнес-архитектура

Связи между бизнес-процессамиБизнес-функцииПодфункцииНовые функции

Архитектура информации

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

20

и управления даннымиАрхитектура приложений

Перечень приложенийТочки доступа к приложениям

Технологическая архитектура

ИнфраструктураПлатформыСистемы храненияСетиБезопасностьСистемное управление

Для описания динамики развития архитектуры предприятия также возможны два структурирования:

последовательность этапов жизненного цикла (life cycle); структура перехода "как есть" "как должно быть" – соотношение

между сегодняшним состоянием архитектуры предприятия (архитектура "как есть"), будущим желаемым состоянием архитектуры (архитектура "как должно быть"), портфелем ИТ-активов и портфелем ИТ-проектов

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

В следующих разделах представлены более детальные описания базовых доменов архитектуры.

1.2.4. Архитектура информацииЕсли бизнес-архитектура отвечает на вопрос: "Кто и что будет делать в

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

Особенности описания архитектуры информации в общем пространстве управления ИТ-проектом представлены в табл. 1.2 [Данилин, Слюсаренко].

Таблица 1.2. абстракция

аспект описания

концептуальный уровень

логический уровень

физический уровень

точка зрения бизнес-взгляд на ИТ ИТ-взгляд на бизнес

ИТ-взгляд на ИТ

фаза планирование анализ реализациярассматриваемые связи

связи данных с бизнес-функциями, интерфейсами, технологиями

связи данных с другими данными

связи данных с системами хранения

21

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

структура данных

объемы и степень использования данных

это, скорее... искусство наука религия (следование рекомендациям вендоров)

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

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

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

В связи с этим на концептуальном уровне абстракции должны быть описаны следующие процессы управления информацией [Gartner]:

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

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

потребителей; обеспечение безопасности информации (например, аутентификация

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

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

решения следующих вопросов [Данилин, Слюсаренко]: идентификация и инвентаризация существующих данных (определение

их источников, процедур изменения и использования, ответственность, оценка качества данных);

22

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

повышение качества данных (исключение неоднозначности и противоречивости различных экземпляров; привлечение бизнес-пользователей к управлению и определению данных);

исключение ненужных перемещений или копирования данных (а первую очередь – большого количества унаследованных или устаревших приложений);

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

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

сокращение числа используемых технологий и продуктов; улучшение защиты данных (защита от несанкционированного доступа).

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

описание существующих источников данных; модели данных, в первую очередь [Gartner]

- фиксации семантической разницы данных из различных источников; - набор относительно стабильных ( "канонических") представлений данных, описывающих их использование бизнес-пользователями;

Замечание: согласно [Gartner], не следует стремиться к созданию и, тем более, поддержанию, полной и непротиворечивой модели данных для всей организации, так как это противоречит семантике информационных потоков и динамике развития бизнеса.

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

описание решений по организации хранения данных – от общих каталогов до витрин и хранилищ данных;

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

1.2.5. Архитектура приложенийАрхитектура приложений отвечает на вопрос: "Какие прикладные

системы нужны предприятию для выполнения бизнес-процессов?" Детализация ответа на этот вопрос позволяет выделить следующие аспекты архитектуры приложений:

23

формирование и управление портфелем прикладных систем предприятия описание существующего набора приложений (в том числе их

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

описание планируемого набора приложений (в аспекте решения планируемых бизнес-задач);

план миграции между ними (в том числе финансовые и временные аспекты);

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

предлагаемые к приобретению и(или) разработке, являются весьма разноплановыми. Для их систематизации может быть полезен следующий подход [Gartner]:

выделить и кластеризовать ключевые бизнес-процессы; разработать для каждого кластера адекватные "архитектурные стили",

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

представлен в табл. 3.

Таблица 1.3Процессы с

большим количеством транзакций

Операции в реальном времени

Аналитические процессы и

бизнес-аналитика

Совместная работа

Корпоративные

(обслуживающие)

Стратегические потребности

Предоставление услуг

Время реакции системы

Способность дать объяснение Поддержка принятия решения

Распространение знаний Скорость Инновации

Надежность Низкая стоимость с точки зрения ИТ

Бизнес-требования

Обслуживание клиентов Уменьшение затрат Работа 24*7 Целостность данных

Экономичность и безопасность Работа 24*7*365

Повышение эффективности и производительности, наглядность представления информации

Скорость выпуска услуг Повторное использование знаний

Экономичность Улучшения в процессах

Отличительные характеристики

Низкая стоимость (на одну транзакцию) Надежность Масштабируемость Производительность Резервирование

Сканирование и фильтрация потока данных Приоритезация запросов Надежность Публикация и подписка на данные

Механизм аналитики Мощность обработки Объединение данных

Простота использования Надежность Высокая пропускная способность Обмен данными "по горизонтали"

Стандартные процессы Кандидаты на аутсорсинг

24

Интегрирующие технологии

Системы интеграции корпоративных приложений

Специально разработанный программный код

Хранилища данных

Совместно используемые данные и обмен данными

Стандартные интерфейсы (API), XML

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

1.2.6. Технологическая архитектураТехнологическая архитектура отвечает на вопрос: "Какие

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

Существуют различные способы категоризации технологий и сервисов, которые относятся к технологической архитектуре. Например, в [Meta Group] выделены два типа доменов технологической архитектуры: базовые (технологии, которые используются практически каждой

информационной системой) – сети, аппаратное обеспечение, операционные системы, системы хранения, программное обеспечение промежуточного слоя (middleware), системы управления базами данных, технологии системного управления ИТ-ресурсами в распределенной среде, архитектура безопасности.

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

В [Gartner] выделены шесть архитектурных компонент (сервисов) технологической архитектуре: Сервисы данных – системы управления базами данных (технологии баз

данных и методы доступа к базам), хранилища данных (хранилища и витрины данных), системы поддержки принятия решений (Business Intelligence – средства анализа и средства подготовки отчетов).

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

25

компонент, серверы приложений, серверы поддержки тонких клиентов), геоинформационные системы и средства.

Программное обеспечение промежуточного слоя (middleware). Вычислительная инфраструктура – операционные системы и аппаратное

обеспечение (приложения для настольных систем, операционные системы для настольных систем, мобильные устройства – ноутбуки, беспроводные устройства, персональные цифровые помощники, серверы приложений/данных, сетевые операционные системы, принтеры), среда для web-инфраструктуры (браузеры, web-порталы, web-серверы, средства управления и создания контента, серверы каталогов, форматы публикации информации), системы хранения (Storage Area Network – сети хранения данных, накопители на магнитных лентах, накопители на оптических дисках и CD, системы хранения высокой надежности RAID), средства системного управления (средства сетевого управления, администрирование IP), топологии (топология распределенных приложений).

Сетевые сервисы – локальные сети (протоколы, кабельные системы, топология), глобальные сети (транспорт, протоколы), технологии доступа (пользователи с удаленным доступом, эмуляция терминалов и шлюзы, беспроводные технологии для локальных и глобальных сетей, интегрированные средства передачи данных и голоса, обеспечение доступности, средства видеоконференций), голосовые технологии (голос/данные поверх IP-протокола, голосовая почта), сетевое аппаратное обеспечение (концентраторы, маршрутизаторы и пр.).

Сервисы безопасности – авторизация, аутентификация (внутренняя и внешняя аутентификация, PKI), сетевая безопасность (Network Firewall, Internet Firewall), физическая безопасность центров обработки данных, прочие сервисы безопасности (обнаружение вторжений, защита от вирусов).

В [TRM] предложена модель, содержащая четыре области технологических сервисов: доступ и доставка; платформы и инфраструктура; компонентная модель; сервис интерфейсов и интеграции. Каждая область технологических сервисов делится на категории, категории содержат стандарты, а стандарты содержат спецификации (рис. 1.6).

26

Рис. 1.6.  Пример областей, категорий, стандартов и спецификаций технической справочной модели TRM FEAF

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

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

самоконфигурирование – организация системы в соответствии с требованиями;

самозащита – предотвращение сбоев в системе в результате нарушения работы компонент системы и потери целостности данных;

самовосстановление – диагностика неисправностей, локализация ошибок и устранение их последствий;

самооптимизация – наиболее рациональное использование имеющихся ресурсов без вмешательства оператора;

повышение эффективности использования существующих вычислительных ресурсов.

27

Соответствующие решения предлагают практически все ведущие производители, включая HP (концепция Adaptive Enterprise, архитектура Darwin), IBM (On Demand), Sun (N1), Microsoft (Dynamic Systems Initiative) и другие. Основные идеи адаптивной инфраструктуры таковы:

все ИТ-ресурсы строятся на сравнительно дешевых компонентах с определенной избыточностью, являются общими и разделяемыми;

выделение ресурсов конкретным приложениям производится автоматически в соответствии с требованиями бизнеса; эти занимается специальная "интеллектуальная" компонента системы – управляющий модуль (IT governor) – на основе мониторинга времени реакции сервисов на запросы, прогнозных и исторических значений потребностей приложений, наличия ошибок/выхода из строя элементов системы и т.п.

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

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

1.2.7. Целеполагание в архитектуре проектаЛюбая проектная деятельность является целевой, т.е. предполагает

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

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

Выделим основные особенности целеполагания в ИТ-проекте: все компоненты целеполагания (руководящие принципы, стандарты,

политики, руководства, процедуры и т.д.) могут относиться ко всем элементам архитектуры – например, к данным, к прикладным системам, к технологической инфраструктуре и т.д.;

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

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

28

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

ключевые элементы философии использования информационных технологий.

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

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

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

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

Руководства или рекомендации (guidelines)– описания лучших практик или приемлемых подходов к практической реализации политик и процедур. Руководства могут стать стандартами.

Соотношение между ними представлено на рис. 1.7.

Уро

вень

общ

ност

и це

ли

Стратегический уровень

Миссия и видениеРуководящие принципыЦели, задачи, стратегииАрхитектура ИТ

Уро

вень

общ

ност

и оп

исан

ияТактический уровень

Политики (правила)ИТ-стандартыПроцедурыРуководства

Рис. 1.7. Соотношение компонентов целеполагания в ИТ-проекте

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

29

примеры формулировки принципов, которые могут относиться кИТ- архитектуре крупного предприятия или к государственной структуры среднего уровня.Примеры декларируемых принципов для архитектуры в целом:

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

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

адаптивной. Архитектура должна быть инструментом реализации изменений. Архитектура должна уменьшать сложность интеграции и

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

Инфраструктура должна быть основана на использовании технологий, поддерживающих открытые стандарты.

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

При проектировании технологической архитектуры должны учитываться тенденции рынка.

Примеры принципов в области управления данными: Бизнес-структуры (отделы, департаменты, ведомства), являющиеся

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

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

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

Данные вводятся в информационные системы один раз, и тут же выполняется проверка их корректности.

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

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

Прикладные системы разрабатываются на основе стандартной, единой методологии.

Будет применяться компонентная разработка информационных систем. Все структурные подразделения (ведомства) используют общие

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

Приветствуется создание межфункциональных прикладных систем.

30

Руководство заранее планирует процесс замены устаревших прикладных систем.

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

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

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

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

ИТ-служба будет использовать стандарты и методику управления качеством "Шесть Сигма" в процессе обеспечения качества прикладных систем и ИТ-услуг (принцип, который может быть принят в результате анализа сильных и слабых сторон ИТ-службы).

Аспекты контроля достижения целей в ИТ-проекте рассматриваются в отдельном разделе.

1.2.8. Модели архитектур – определения и классификацияКак уже отмечалось ранее, между архитектурой предприятия в целом и

ИТ-архитектурой существует тесная связь. То же относится и к моделям этих архитектур.

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

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

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

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

31

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

функциональные (организационно-функциональные) модели; потоковые модели; структурные модели; объектные модели.

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

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

Главный упор при функциональном моделировании делается на выполнение элементами системы (например, ИТ-системы) некоторых функций Моделирование проводится по принципу декомпозиции функций системы "от большого к малому" (вплоть до простых передаточных функций)..

Рис. 1.8. Пример алгоритма

Функциональный подход используется, например, в методологии бизнес-моделирования ARIS [Сравнительный], использующей нотацию eEPC При помощи этой нотации можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций). Примеры моделей некоторых бизнес-процессов, построенных с использованием ARIS eEPC, показаны на рис. 1.9, 1.10. Идеи функционального моделирования поддержаны ГОСТ Р 50.1.028-2001. МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ.

32

Рис. 1.9. Модель бизнес-процесса в нотации ARIS eEPC

Рис. 1.10. Модель бизнес-процесса в нотации ARIS eEPC

Потоковая модель представления бизнес-процесса связана с описанием процесса как потока объектов (поток на входе – преобразование – поток на выходе). В качестве потоков могут выступать информация, документы, материальные поставки, другие ресурсы. Такие потоковые модели применяются в рамках рассмотрения отдельных задач и рассмотрения деятельности компании и ее подразделений в форме «вход-выход». На вход поступают ресурсы, на выходе получаем продукты (услуги) (рис. 1.11).

33

Рис. 1.11. Пример потокового описания бизнес-процесса

В структурных моделях информация группируется вокруг структур данных. Среди многообразия средств, предусмотренных для проведения структурного анализа, можно назвать: DFD (Data Flow Diagrams) – диаграммы потоков данных в нотациях

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

STD (State Transition Diagrams) – диаграммы перехода состояний, основанные на расширениях Хартли и Уорда–Меллора для проектирования систем реального времени;

ERD (Entity-Relationship Diagrams) – диаграммы «сущность-связь» в нотациях Чена и Баркера;

структурные карты Джексона и/или Константайна для проектирования межмодульных взаимодействий и внутренней структуры объектов;

FDD (Functional Decomposition Diagrams) – диаграммы функциональной декомпозиции.

Однако наиболее известной методологий структурного моделирования является методология SADT (Structured Analysis and Design Technique – технология структурного анализа и проектирования), в состав которой входит семейство методологий IDEF (Integration Definition for Function Mod-eling): IDEFO – методология функционального моделирования, являющаяся

составной частью SADT и позволяющая описать бизнес-процесс в виде иерархической системы взаимосвязанных функций;

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

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

34

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

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

IDEF4 – методология объектно-ориентированного проектирования для поддержки проектов, связанных с объектно-ориентированными реализациями;

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

Нотация IDEF0 была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий. Нотация IDEF3 была разработана с целью более удобного описания рабочих процессов (Work Flow), для которых важно отразить логическую последовательность выполнения процедур.

Бизнес-процесс, сформированный при помощи нотации IDEF0, показан на рис. 1.12. (Этот же процесс представлен в нотации ARIS eEPC на рис. 1.9).

Рис. 1.12. Модель бизнес-процесса в нотации IDEF0На рис. 1.13 показан бизнес-процесс, описанный при помощи нотации

IDEF3. (Этот процесс представлен в нотации ARIS eEPC на рис. 1.10).

35

Обратим внимание, что В нотации IDEF3, так же как и в нотации ARIS eEPC, используются символы логики, отражающие ветвление процесса.

Рис. 1.13. Модель бизнес-процесса в нотации IDEF3В объектно-ориентированной среде информация группируется внутри

классов или объектов (инкапсуляцией как данных, так и процессов). Такой способ моделирования применяется в основном не для описания бизнес-процессов, а для описания определенных аспектов ИТ-систем.

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

Между отдельными модельными представлениями процессной модели имеется взаимосвязь, которая закрепляется соответствующими документами и поддерживается посредством ИТ-системы.

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

36

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

Рис. 1.14. Компоненты процессно-ориентированной системы бизнеса в некоторой компании

Такое закрепление фиксируется документально. В частности, стандартный документ – Положение о подразделении – фиксирует закрепление функций за данным подразделением. С 1986 г. требование о необходимости функционального описания и закрепления функций за звеньями стало одним из основных в стандарте ISO серии 9000. В 1994 г. в этом стандарте предусмотрена необходимость закрепления за подразделениями не только функций, но и процессов.

Стандарт ISO серии 9000 предусмотрел необходимость использования процессной модели деятельности организации, которая содержит большее число характеристик, чем функциональная модель (рис. 1.14). В частности,

37

появилась модель закрепления ответственности, а также матрицы соответствия других типов: процессы – звенья, функции-звенья, звенья-звенья, фнкции-функции.

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

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

1.2.9. Фреймворки в моделировании архитектурыНа основе рассмотренных выше типовых способов построения моделей

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

модель Захмана; методики, опубликованные аналитическими компаниями, такими как

Gartner, Giga Group, META Group и другими; методика TOGAF; модель "4+1"; методики Microsoft.

Существуют также индустриальные стандарты на описание архитектуры предприятия, принятые такими организациями, как Институт инженеров электрики и электроники (IEEE – Institute of Electrical and Electronics Engineers), международная организация стандартизации (ISO – International Organization for Standardization), The Open Group и т.д.. Например, это методика POSIX 1003.23, которая основывается на разработках компании Cap Gemini, переданных для публичного использования в 1996 году.

38

Модель Захмана [Захман] представляется в виде таблицы, имеющей пять строк и шесть столбцов, которая приведена на рис. 1.15. Отображенная на рисунке шестая строка соответствует уже не уровню описания архитектуры, а уровню работающей системы или предприятия в целом.

Рис. 1.15.  Модель Захмана

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

Модель Gartner 2002 года [Gartner] сформулирована в виде четырех связанных, взаимозависимых и усложняющихся уровней (рис. 13):

среда бизнес-взаимодействия (Business Relationship Grid); бизнес-процессы и стили бизнес-процессов; шаблоны; технологические строительные блоки.

При этом уровни ИТ-архитектуры соответствуют различным уровням выполнения операций реального бизнеса (рис. 1.16).

39

Рис. 1.16.  Уровни модели архитектуры Gartner

Рис. 1.17.  Архитектура ИТ в бизнес-контексте

40

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

Архитектурная методика META Group [Meta Group] рассматривает архитектуру предприятия в интеграции с другими ключевыми процессами, в частности, с процессом управления корпоративными ИТ-программами и проектами (EPM – Enterprise Program Management) и процессом выработки стратегии и планирования. Считается, что архитектура реализуется на практике через процесс управления ИТ-программами и проектами. Объединяющим для всех доменов архитектуры META Group является процесс формулировки бизнес-требований к ИТ-архитектуре, что оформляется в виде двух документов: Видения общих требований (CRV – Common requirements Vision) и Принципах концептуальной архитектуры (CA – Conceptual Architecture) (рис. 1.18)

Рис. 1.18.  Аналитическая работа и компоненты Архитектуры предприятия

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

Методика описания архитектуры TOGAF (The Open Group Architecture Framework) [TOGAF] была предложена некоммерческим

41

объединением The Open Group, в которое входит ряд ведущих производителей информационных технологий. Основным полем для применения TOGAF является, прежде всего, программная инфраструктура информационной системы (в противоположность таким типам архитектур, как бизнес-архитектура, архитектура данных и приложений). Таким образом, она в наилучшей мере подходит для описания интеграционных компонент, использующихся для поддержки широкого спектра корпоративных приложений, прежде всего, критичных для бизнеса (mission-critical). Последняя версия была существенно расширена за рамки технологической архитектуры и включает бизнес-архитектуру, архитектуру данных и архитектуру приложений. Теперь это одна из самых полных методик, которая к тому же доступна бесплатно (лицензируется только коммерческое использование).

Общая структура TOGAF показана на рис. 1.19.

Рис. 1.19.  Структура TOGAF

Модель "4+1" позиционируется, прежде всего, как способ описания архитектуры систем, основанных на активном использовании программного обеспечения, хотя эти идеи могут использоваться и в более широком контексте архитектуры предприятия.

42

Рис. 1.20.  Модель "4+1"

Модель описывает архитектуру сложных систем путем использования пяти различных категорий или представлений (views):

логическое представление является объектной моделью проектирования (в том случае, если используется объектно-ориентированная модель проектирования);

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

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

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

сценарное представление содержит некоторые отобранные сценарии использования (use cases). Архитектура системы во многом определяется этими сценариями.

Каждое представление отражает специфические аспекты моделируемой системы.

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

Архитектурные концепции и методики Microsoft [Microsoft], [Microsoft _Journal] покрывают различные аспекты архитектуры. Базовые методики Microsoft ориентированы на следующие основные вопросы:

MSF – "Как правильно создавать ИТ-системы?" MSA – "Как правильно создавать технологическую инфраструктуру?"

43

MOF – "Как правильно эксплуатировать технологическую инфраструктуру?"

MSM – "Как правильно строить процессы управления технологической инфраструктурой?"

Другими словами, каждая из методик ориентирована на свой уровень абстракции (концептуальной, логической и физической архитектур системы): методики MSF и MSA в большей степени относятся к процессу разработки архитектуры прикладных систем и инфраструктуры соответственно, а методики MOF и MSM – к архитектуре системного управления, т.е. вопросам управления и эксплуатации. В реальности для описания каждой из перспектив могут использоваться и несколько различных моделей.

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

Разработка информационных систем с помощью MSF ведется в соответствии с концепцией "приоритета архитектуры": высокоуровневая архитектура (на уровне предприятия) полностью формируется до начала разработки и определяет направление работы.

Рис. 1.21.  Архитектурные перспективы, шаблоны и методики Microsoft

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

44

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

1.2.10. Выбор методологии моделирования архитектурыИмеется множество методик описания архитектуры, и все они разбивают

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

Таблица 1.4.Домены

Бизнес-архитектура

Архитектура информации

Архитектура приложений

Технологическая архитектура

Перспективы (уровни

абстракции)Контекст ("планировщик")

Классы бизнес-процессов (группа процессов, имеющих много общих активностей) Список бизнес-процессов

Список бизнес-сущностей – объектов, важных для бизнеса ("клиент", счет") Связи между сущностями (бизнес-объектами)

Список бизнес-процессов

Список мест расположения бизнеса

Концептуальный уровень ("владелец" предприятия)

Сценарии использования (Use case) Модели бизнес-процессов

Семантические модели Модели связей Модели "сущность-связи"

Разбиение процессов на сервисы

Модели бизнес-логистики Операционные (нефункциональные) требования Архитектура расположения элементов центра обработки данных

Логический ("проектировщик")

Модели процессов

Логические модели данных

Определения сервисов

Логические типы серверов: БД,

45

(потоков работ) Модели бизнес-событий Модель расположения процессов Определения ролей

Схемы данных Спецификации документов

Взаимосвязи между сервисами Модели классов

почтовые, транзакционные, … Географическое распределение серверов Хостируемое ПО

Физический ("разработчик")

Спецификации процессов Модели интеграции процессов Описание ручных процедур Стандарты качества

Физические модели данных Схемы БД Код доступа к данным Справочники данных

Код программ Описания интерфейсов (WSDL) Расписания процессов Код workflow

Физические серверы Топология фрагментов сети Мапирование продуктов на сервисы и приложения

1.3. Процессы жизненного цикла и методологии их описания

1.3.1. Классификации моделей жизненного цикла разработки ПОЛюбой проект в процессе своей реализации проходит различные стадии,

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

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

Модели процесса обычно строятся в виде графика «когда–что», в котором:

по оси времени располагаются динамические характеристики процесса –моменты начала и окончания чего-то (циклов, фаз, итераций), а также milestones),

по другой оси – статические аспекты (результаты, исполнители, последовательности действий – workflows).

Как уже говорилось ранее (раздел 1.1.6), в связи с высокой сложностью, связностью и неопределенностью структуры ПО и ЖЦ разработки ПО существуют и параллельно используются несколько классификаций ЖЦ, соответствующих его декомпозиции по различным основаниям, в том числе: по уникальность / тиражируемости проектируемого ПО

каноническое проектирование типовое проектирование

по логической последовательности работ в ЖЦ

46

каскадная (водопадная – waterfall), инкрементальная (эволюционная), спиральная.

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

Исследование и обоснование создания системы Разработка концепции системы Разработка технического задания на систему Эскизное проектирование Техническое проектирование Рабочее проектирование Ввод в действие Сопровождение

Процесс канонического проектирования и его поддержка стандартами подробно рассматривается далее (см. разделы 1.4 и 1.5).

Типовое проектирование ИС предполагает создание системы из готовых типовых элементов. Базовым компонентом типового проектирования является типовое проектное решение (ТПР) – тиражируемое (пригодное к многократному использованию) проектное решение. ТПР подразделяются на:

элементные ТПР – типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному)

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

объектные ТПР – типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.

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

Для типового проектирования существуют ППП инструментальной поддержки (например, Solution Framework), рассматриваемые в части 2 .

Каскадная (водопадная) модель (W.W. Royce, 1970 г.). Разработка основана на выполнении одной цепочки проектирования в соответствии с заранее определенными требованиями (рис. 1.22).

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

47

разработки к другой происходит только после полного и успешного завершения предыдущей фазы, а переходов назад либо вперед или перекрытия фаз не происходит.

Модель имеет явные недостатки, которые осознавались и самим Ройсом: от руководителя проекта требуется минимальная квалификация, а

ответственность за успех проекта переносится на специалистов; недостаточная гибкость модели; формальное управление проектом часто становится самоцелью (в ущерб

срокам, стоимости и качеству). Однако она имеет и достоинства:

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

сложившаяся практика оформления договорных отношений исторически тяготеет к подобной модели.

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

Проектиро-вание

Реализация (кодирование)

Интеграция

Тестирова-ние

Результат - спецификация (текст)

Результат - программы и текст

Результат - программный код и комментарии

Результат - исходный код

Результат - отчет о тестировании с описанием дефектов

Время

Фазы, результаты

Рис. 1.22. Каскадная модель

Поэтому на базе модели водопада разработаны модели водопада, имеющие небольшие или даже значительные вариации описанного процесса. Так, в 3-ей версии стандарта по управлению проектом [PMBOK] формально была закреплена только методика водопада. Однако, начиная с PMBOK 4-ой версии (2009 г.), в качестве стандарта предлагается гибридный вариант, сочетающий в себе как плюсы модели водопада, так и достижения итеративных методологов. Основные изменения: разрешены перекрытия фаз; поддерживаются итеративные методы и создание прототипа.

Возможны и комбинированные варианты управления проектами.

48

Например, подпроект проектирования может с фиксированным сроком и бюджетом вестись итеративно, а подпроект строительства может выполняться по методике "водопада". Такой комбинированный вариант поддерживается в Turbo Project [Turbo Project] (компонент для Microsoft Project, который автоматизирует создание проектов "сверху вниз").

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

Инкрементальная модель – это, по существу, модель постоянного расширения ИТ-системы (рис. 1.23).

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

Рис. 1.23. Инкрементальная модель

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

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

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

49

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

Модель принято изображать в виде спирали (рис. 1.24), причем чем дальше от центра, тем лучше результаты.

Рис. 1.24. Спиральная модель ЖЦ в виде цикла Боэма

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

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

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

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

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

Как правило, все требования к системе не удается сформулировать заранее, поэтому главная проблема – удачная стартовая версия (прототип).

50

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

Модель сложна с точки зрения управления и в чистом виде применяется достаточно редко. Как правило, она совмещается с другими усложненными методиками управления. Происходит n-кратное (обычно три раза – альфа, бета, релиз) прохождение стадий построения ИТ-системы. Такой вариант ЖЦ показан на рис. 1.25.

Классическая спиральная модель ориентирована на большие, дорогостоящие и сложные проекты. Имеются ее модификации (например, Spiral Architecture Driven Development [SADD]), ориентированные на работу в условиях изменяющихся бизнес-целей при сохранении стабильной архитектуры, удовлетворяющей высоким требованиям по нагрузке и устойчивости.

Время

Фазы, результаты

Анализ требований 1 Проектиро-

вание 1 Реализация (кодирование) 1 Интеграция 1

Тестиро- вание 1

Анализ требований 2 Проектиро-

вание 2 Реализация (кодирование) 2 Интеграция 2

Тестиро- вание 2

Анализ требований n Проектиро-

вание n Реализация (кодирование) n Интеграция n

Тестиро- вание n

Рис. 1.25. Спиральная (эволюционная) модель с тремя итерациями

1.3.2. Методологии проектирования ИТ-системМетодология проектирования ИТ-систем – набор стандартизованных и

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

51

сопровождению ИТ-систем, т.е. вносят в процесс создания ПО инженерный подход.

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

Как получится (code&fix) Cleanroom Software Engineering Итеративная

RUP   OpenUP MSF  

RAD   Agile

Agile Modeling Agile Unified Process (AUP) Agile Data Method DSDM Essential Unified Process (EssUP) Extreme programming, XP Feature Driven Development (FDD) Getting Real Open Unified Process (OpenUP) Scrum Бережливая разработка программного обеспечения (Lean

Software Development) КанБан FDD

1.3.3. Методология code&fix ("Как получится")Сode&fix – это отсутствие какого-либо сознательно выбранного метода.

Разработчики, ознакомившись с задачей, практически сразу начинают писать код. Конечно, в каждой команде свой подход к разработке, тем не менее, и в них можно выявить некоторые общие черты: процесс состоит из двух стадий: написание кода – исправление проблем. крайне низкий уровень формализма разработки; правил ведения

разработки либо нет вообще, либо они разработаны и приняты, но не выполняются.

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

применять на уровне промышленного программирования.

1.3.4. Cleanroom Software EngineeringCleanroom Software Engineering (методология «чистой комнаты») (Х.

Миллз, 1980-е гг.) + процесс разработки программного обеспечения, предназначенный для создания программного обеспечения с

52

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

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

инкрементальная реализации в рамках статистического контроля качества;

статистическое тестирование; формальная верификация.

1.3.5. Итеративная модельИтеративный подход (iteration – повторение) – выполнение работ

параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование – Реализация – Проверка – Оценка (англ. plan-do-check-act cycle) (рис. 1.26).

Рис. 1.26. Итеративная модель разработки

Преимущества итеративного подхода: снижение воздействия серьезных рисков на ранних стадиях проекта,

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

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

акцент усилий на наиболее важные и критичные направления проекта; непрерывное итеративное тестирование, позволяющее оценить

успешность всего проекта в целом; раннее обнаружение конфликтов между требованиями, моделями и

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

53

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

В качестве примеров реализации итеративного подхода ниже рассматриваются методологии разработки программного обеспечения, созданные компанией Rational Software – Rational Unified Process (RUP)  и его облегченный вариант Open Unified Process/

1.3.6. Rational Unified ProcessRational Unified Process (RUP) базируется на унифицированном процессе

разработки ПО (USDP), который был предложен создателями ООП (Якобсон, Буч, Рембо). Соответствующий стандарт принят консорциумом Object Managing Group (OMG) в 1997 г.

RUP – это методология создания программного обеспечения, оформленная в виде размещаемой на Web базы знаний, которая снабжена поисковой системой.

Рис. 1.27. Графическое представление процесса разработки по RUP

54

RUP использует итеративную модель разработки. Полный жизненный цикл разработки продукта (рис. 1.27) состоит из четырех фаз, каждая из которых включает в себя одну или несколько итераций.1. Начало (inception) – предварительное взаимодействие с

заинтересованными лицами (заказчик, пользователи, инвесторы и др. stakeholders) (на рис. 1.27 – 1 итерация). На этом этапе формируются видение и границы проекта, создается экономическое обоснование, определяются основные требования, ограничения и ключевая функциональность продукта, создается базовая версия модели прецедентов, оцениваются риски.

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

3. Конструирование (construction) – реализация большей части функциональности продукта. Фаза завершается первым внешним релизом системы, т.е. выпуском работоспособной версии (базового продукта) (на рис. 23 – 3 итерации).

4. Внедрение (transition)– создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. Фаза заканчиваются выпуском готового продукта В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова (на рис. 23 – 1 итерация).

В матрице RUP (рис. 1.27) итерации (время) расположены по вертикали, а по горизонтали – рабочие процессы (workflows), которые разделены на рабочие процессы процесса (core process workflows)

бизнес-моделирование требования анализ и проектирование реализация (implementation – выполнение) тестирование развертывание (deployment)

и рабочие процессы поддержки (core supporting workflows) управление конфигурациями управление взаимодействие с окружением.

На каждой итерации по вертикали показывается распределение усилий (content) между технологическими процессами (workflows). Например, на рис. 24 на второй итерации перехода выполняется только тестирование и развертывание.

Модельные элементы процесса RUP (рис. 1.28):

55

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

Задача – это единица работы, выполнение которой можно потребовать от конкретной роли.

Артефакт – объект и/или результат работы Рабочий процесс является способом описания последовательностей задач,

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

а б вРис. 1.28. Примеры артефактов проекта в нотации UML: а – документ, б – модель (например, use case диаграмма), в – физический компонент (например, исходный код)

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

1.3.7. OpenUPOpenUP [OpenUP] – это итеративно-инкрементальный метод разработки

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

Рис. 1.29. Жизненный цикл OpenUP

OpenUP делит жизненный цикл проекта на четыре фазы: начальная фаза, фазы уточнения, конструирования и передачи (рис. 1.29). Внутри фаз возможны итерации – планируемые, ограниченные во времени интервалы,

56

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

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

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

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

1.3.8. Microsoft Solutions FrameworkМетодология Microsoft Solutions Framework (MSF) водит в состав

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

Выделим специфику методики MSF (Microsoft Solutions Framework) [MSF]. Компонентами MSF являются: Базовые принципы – выражают основные ценности и стандарты,

применимые ко всем элементам методики; Модели MSF– карты организации проектных групп и процессов работы,

включающие Модель команд и Модель процессов. Дисциплины MSF– управление рисками (risk management), управление

подготовкой (readiness management) и управление проектами (project management).

Проверенные практические методики (практики) MSF – анализ результатов после контрольной точки, определение и контроль факторов риска и т.д.

Рекомендации MSF – рекомендуемые практики и руководства, связанные с применением моделей и дисциплин MSF.

Модель проектной группы MSF (MSF Team Model) (см. подробное описание в разделе 3.1.3) описывает подход к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта. Проектные группы строятся как небольшие многопрофильные команды, члены которых распределяют между собой ответственность и дополняют области компетенций друг друга. Это дает возможность четко сфокусировать внимание на нуждах проекта. Проектную группу объединяет единое видение проекта, стремление к воплощению его в жизнь, высокие требования к качеству работы и желание самосовершенствоваться.

57

Проектная группа по MSF состоит из шести ролевых кластеров, каждый из которых отвечает за: управление программой (program manager) – разработку архитектуры

решения, административные службы; разработку (developer) – разработку приложений и инфраструктуры,

технологические консультации; тестирование (QAE) – планирование, разработку тестов и отчетность по

тестам; управление выпуском (release manager) – инфраструктуру, сопровождение,

бизнес-процессы, выпуск готового продукта; удовлетворение заказчика (user experіence) – обучение, эргономику,

графический дизайн, техническую поддержку; управление продуктом (product manager) – бизнес-приоритеты, маркетинг,

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

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

Модель процессов MSF (MSF process model) сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral). Модель процессов включает основные фазы процесса разработки:Выработка концепции (Envisioning)Планирование (Planning)Разработка (Developing)Стабилизация (Stabilizing)Внедрение (Deploying)и большое количество промежуточных вех. Разработка ведется итеративными методами. MSF рекомендует начинать разработку решения с построения, тестирования и внедрения его базовой функциональности. Затем к решению добавляются все новые и новые возможности. Такая стратегия именуется стратегией версионирования. С созданием новых версий эволюционирует функциональность решения. В рамках MSF предлагается ряд шаблонов стандартных документов, которые являются артефактами каждой стадии разработки продукта и могут быть использованы для планирования и контроля процесса разработки.

Методология MSF появилась в 1994 г. и постоянно развивается: в частности, произошло разделение методологии на два направления: MSF for Agile Software Development и MSF for CMMI Process Improvement.

1.3.9. Rapid application development  RAD (rapid application development – быстрая разработка приложений) –

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

58

особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы. Концепцию RAD также часто связывают с концепцией визуального программирования. Основателем RAD считается сотрудник IBM Джеймс Мартин, который в 1980-х годах сформулировал основные принципы RAD, основываясь на идеях Барри Бойма и Скотта Шульца.

Основные принципы RAD Инструментарий должен быть нацелен на минимизацию времени

разработки. Создание прототипа для уточнения требований заказчика. Цикличность разработки: каждая новая версия продукта основывается

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

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

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

разработки.Среды разработки, частично использующие принципы RAD

Axure RP C++ Builder Clarion Code::Blocks Delphi DevelStudio IBM Lotus Domino Designer IntelliJ IDEA IntraWeb Lazarus Macromedia Flash Macromedia Authorware Macromedia Director Microsoft Visual Studio Miracle MonoDevelop NetBeans IDE Omnis Studio PowerBuilder QDevelop (в связке с Qt-Designer) SharpDevelop Visual DataFlex WxDev-C++ wxFormBuilder

59

1.3.10. Гибкие методологии (Agile software development) Рассмотренные выше методологии – "тяжелые методологии". Они дают

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

Гибкая методология разработки (Agile software development) [Agile] – это концептуальный каркас, в рамках которого выполняется разработка программного обеспечения. Agile – семейство процессов разработки, который определяется Agile Manifesto (разработан и принят 11-13 февраля 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты). Agile Manifesto cодержит 4 ценности и 12 принципов, которыми руководствуются успешные команды, и не содержит практик.Ценности Agile Manifesto:

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

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

Принципы Agile Manifesto удовлетворение клиента за счет ранней и бесперебойной поставки

ценного ПО; приветствие изменения требований, даже в конце разработки (это

может повысить конкурентоспособность полученного продукта); частая поставка рабочего ПО (каждый месяц или неделю или еще

чаще); тесное, ежедневное общение заказчика с разработчиками на

протяжении всего проекта; проектом занимаются мотивированные личности, которые обеспечены

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

(лицом к лицу); работающее ПО — лучший измеритель прогресса; спонсоры, разработчики и пользователи должны иметь возможность

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

удобный дизайн; простота — искусство НЕ делать лишней работы; лучшие архитектура, требования и дизайн получаются у

самоорганизованной команды; постоянная (частая) адаптация (улучшение эффективности работы) к

изменяющимся обстоятельствам.

60

Спектр методологий, которые придерживаются ценностей и принципов, заявленных в Agile Manifesto, постоянно расширяется, некоторые из них:

Agile Modeling Agile Unified Process (AUP) Agile Data Method DSDM Essential Unified Process (EssUP) Экстремальное программирование (Extreme programming, XP) Feature Driven Development (FDD) Getting Real Open Unified Process (OpenUP) Scrum Бережливая разработка программного обеспечения (Lean Software

Development)Большинство гибких методологий нацелены на минимизацию рисков

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

Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе, иногда называемом bullpen. Как минимум, она включает и «заказчиков» (product owner - заказчик или его полномочный представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент). Команда может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров. Agile-методы ориентированы на максимально неформальный подход к разработке. Если проблему можно решить в разговоре, то лучше именно так и сделать, а оформлять принятое решение в виде бумажного или электронного документа нужно только тогда, когда без этого невозможно обойтись.

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

61

Ниже рассматриваются некоторые, достаточно популярные на сегодняшний день, методологии семейства agile-методов.

1.3.11. Экстремальное программированиеМетодология экстремального программирования (Кент Бек, Уорд

Каннингем, Мартин Фаулер) [Бек] основана на следующих принципах:1. целью разработки ставится скорейшее создание реально работающей

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

образуется путем последовательной "пристройки" друг к другу отдельных модулей ("историй пользователя" – рис. 1.30), которые задает клиент;

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

Отображение отсканированной единицы

товара После сканирования упаковки вверху терминала появляется краткое описание товара и его цена

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

Рис. 1.30. Примеры историй пользователя для ИТ–системы документооборота в магазине

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

5. программы пишутся парами – по два человека за одним компьютером (один пишет код, другой думает над архитектурой); фактически это форма непрерывного инспектирования друг друга;

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

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

62

1.3.12. Методология SCRUMScrum [SCRUM ] – одна из самых популярных методологий гибкой

разработки. В методологии Scrum всего три роли. Scrum Master – Скрам Мастер Product Owner – Владелец процесса Team – Команда

Скрам Мастер является интерфейсом между менеджментом и командой. Как правило, эту роль в проекте играет менеджер проекта или тимлид. Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды: в Agile команда является самоорганизующейся и самоуправляемой. Скрам Мастер ведет Daily Scrum Meeting и отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте. ScrumMaster может также помогать Product Owner создавать Backlog для команды

Рис. 1.31. Схема коммуникаций в Scrum

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

63

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

Команда в Scrum кроссфункциональна (рис. 1.31). В нее входят люди с различными навыками – разработчики, аналитики, тестировщики. Команда берет на себя обязательства по выполнению объема работ на спринт перед Product Owner. Работа команды оценивается как работа единой группы. Команда отвечает за оценку элементов баклога, принимает решение по дизайну и имплементации, разрабатывает софт и предоставляет его заказчику. Типичный размер команды – 72. . Для облегчения коммуникаций команда должна находиться в одном месте (colocated).

Основными артефактами проекта в Scrum являются Product Backlog, Sprint Backlog и Sprint.

Product Backlog (рис. 1.32) – это приоритезированный список имеющихся на данный момент бизнес-требований и технических требований к системе. Product Backlog постоянно пересматривается и дополняется - в него включаются новые требования, удаляются ненужные, пересматриваются приоритеты.

Sprint Backlog (1.33) содержит функциональность, выбранную Product Owner из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач. Сумма оценок оставшейся работы может быть построена как график зависимости от времени (Sprint Burndown chart) (рис. 1.34). Он демонстрирует прогресс команды по ходу спринта. Sprint Backlog не может быть изменен никем, кроме команды.

64

Рис. 1.32. Пример Product Backlog

65

Рис. 1.33. Пример Spint Backlog

Рис. 1.34. Пример Sprint Burndown chart В Scrum итерация называется Sprint. Ее длительность составляет 1 месяц

(30 дней). Результатом Sprint является готовый продукт (build), который можно передавать (deliver) заказчику. Короткие спринты обеспечивают быструю обратную связь от заказчика к проектной команде. Каждый спринт представляет собой маленький "водопад". В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта. Ежедневно в ходе спринта проходят короткие информационные собрания (meetings) команды, а к конце спринта проводится собрание длительностью 4 часа, когда команда демонстрирует инкремент продукта, созданный за последний спринт.

1.3.13. Методология КанбанМетодология Канбан [сводка] была разработана на фирме Тойота как

реализация принципа бережливого производства и описывается тремя основными принципами:

Визуализируйте производство Разделите работу на задачи, каждую задачу напишите на

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

положение задачи в производстве. Ограничивайте WIP (work in progress или работу, выполняемую

одновременно) на каждом этапе производства Измеряйте время цикла (среднее время на выполнение одной задачи) и

оптимизируйте постоянно процесс, чтобы уменьшить это время.

66

Если в SCRUM основная ориентация команды – это успешное выполнение спринтов, то в Канбан на первом месте задачи. Спринтов нет, команда работает над задачей с самого начала и до завершения. Деплоймент задачи делается тогда, когда она готова. Команда не должна оценивать время на выполнение задачи, ибо это, по мнению идеологов Канбан, имеет мало смысла и почти всегда ошибочно вначале. Задача менеджера – это и адекватно изменять приоритизированный пул задач, а задача команды – выполнить как можно больше задач из этого пула.

Команда для работы использует Канбан-доску (рис. 1.35). Столбцы доски имеют следующее содержание. Цели проекта – сюда помещаются высокоуровневые цели проекта, чтобы

команда их видела и все про них знали. Очередь задач – список задач, готовых для выполнения. Всегда для

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

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

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

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

Деплоймент – как предусмотрено в проекте (выложить новую версию продукта на сервер, сохранить код в репозитории и т.д.)

Закончено – все работы по задаче закончены полностью.

Рис. 1.35. Схема доски КанбанДля срочной, но не запланированной задачи выделяется специальное

линия исполнения (“Expedite”). Цифры под каждым столбцом показывают

67

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

Задачи на доске Канбан имеют размер Minimal Narketing Feature (ММФ), т.е. имеют маркетинговый смысл для клиентов – например, Добавить русскую локализацию в продукт, Изменить внешний вид интерфейса под новые стандарты – и рассчитаны на выполнение в течение 1–2 недель.

Использование методологии Канбан дает следующие преимущества: уменьшение числа параллельно выполняемых задач уменьшает время

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

сразу видны узкие места, которые "расшиваются" силами всей команды; можно вычислить время на выполнение усредненной задачи и другую

статистику, которую использовать для дальнейшего планирования; однако Канбан подходит не для всех команд.

1.3.14. Сравнение методологийВ среде разработчиков, в том числе в Интернет, активно обсуждаются

разные методологии. Небольшой дайджест мнений [сводка] представлен ниже.Все существующие методологии можно расположить на шкале

"формальное планирование и контроль" – "командная работа и чистое доверие", причем Agile-методологии расположены на "правой" стороне этой шкалы. Тем не менее, проверить, принадлежит ли конкретная методология семейству Agile, невозможно. Манифест Agile не может служить таким определением, так как, во-первых, слишком размыт, во-вторых, направлен против Waterfall. Принципам манифеста соответствует практически любой Code&Fix проект. RUP также нигде не противоречит принципам agile. В то же время некорректно сравнивать Agile и RUP из-за полной неопределенности первого.

Методологии Scrum и XP являются более или менее определенными. Так, например, существует тест на соответствие Scrum (так называемый Nokia Test) или XP. Если применить Scrum и XP или другую определенную методологию в чистом виде невозможно по тем или иным причинам, то внедряется некоторый процесс, заимствующий практики и принципы из других методологий Agile семейства, плюс какие-то практики из других методов.

Зона применения "чистого" Scrum и XP формируется следующими характеристиками проекта: относительно небольшие команды (до 10 человек); проекты, не являющиеся life-critical и из нерегулируемого бизнес-домена; не строго фиксированная цена проекта; не требуется длительный цикл тестирования; нераспределенная разработка.

Зона применения Канбан описывается такими характеристиками:

68

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

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

Практически все отдельные элементы agile-методик применялись и раньше, но Agile за счет системных эффектов выводит их на новый уровень: их взаимное воздействие и активное применение действует на команду сильнее, чем просто отдельное использование практик. Например, тотальное использование Unit Tests сильно облегчается в TDD и просто необходимо для эффективного рефакторинга. В этом случае возможна Emerging Acrhitecture. Совместное планирование в Scrum обеспечивает общую ответственность за результат, что работает только в случае полной прозрачности работы внутри итерации (Daily Scrum и Demo) и коррекции процесса по ходу работы (Ретроспектива).

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

69