«Гусарова Н.Ф. МЕТОДОЛОГИЯ ОРГАНИЗАЦИИ ПРОЕКТИРОВАНИЯ И РАЗРАБОТКИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ Учебное пособие Санкт-Петербург 2012 Предисловие Настоящее учебное пособие составлено в соответствии с рабочей программой ...»

Национальный исследовательский университет

информационных технологий, механики и оптики

Гусарова Н.Ф.

МЕТОДОЛОГИЯ ОРГАНИЗАЦИИ

ПРОЕКТИРОВАНИЯ И РАЗРАБОТКИ

ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

Учебное пособие

Санкт-Петербург

2012

Предисловие

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

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

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

основные метрики процесса проектирования и разработки по;

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

задачи средств информационной поддержки процессов управления ЖЦ ПО;

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

методологии организации проектирования ИТ-систем;

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

задачи и взаимосвязь этапов проектирования и разработки ПО при различных моделях ЖЦ;

применение методик описания архитектуры ПО;

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

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

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

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

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

ЧАСТЬ 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. Bremen: Eigenverlag, 1999. Р. личающееся от других подобных предприятий специфической проектной организацией;

23.

это предпринимаемое усилие, организующее человеческие, IPMA - International материальные и финансовые ресурсы в неизвестный путь в Project Management Assoрамках уникального предмета работы, заданной спецификаciation ции, с ограничениями на затраты и время, с тем, чтобы следование стандартному жизненному циклу проекта приводило к осуществлению успешных изменений, определенных посредством количественных и качественных целей и задач;

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

это уникальный процесс, состоящий из набора взаимоувязанISO/TR 10006: 1997 (E).

Quality Management – ных и контролируемых работ с датами начала и окончания и предпринятый, чтобы достичь цели соответствия конкретным Guidelines to quality in project management Р. 1. требованиям, включая ограничения по времени, затратам и ресурсам.

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

';

tional Competence Standard for Project Management – Guidelines 1996. Р.

18.

это уникальная совокупность скоординированных действий British Standard BS 6079работ) с определенными точками начала и окончания, предProject management — Part 1: Guide to принятая индивидуумом или организацией для достижения Project management. Р. 2. определенных целей с установленными сроками, затратами и параметрами выполнения.

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

Project Management Body of Knowledge. PMI Standards Committee. 4 Edition, 2000.. (PMBоK) Таблица 1. Некоторые определения термина «проект»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уникальность проекта – понятие слабо формализуемое.

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

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

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

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

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

Основные ограничения проекта:

1. время (срок окончания проекта);

2. деньги (бюджет проекта);

3. качество (соответствие ТЗ и/или пожеланиям потребителя);

4. квалификация персонала;

5. интенсивность труда.

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

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

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

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

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

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

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

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

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

Рис. 1.1. Пространство управления проектом В большинстве случаев ведущей координатной осью пространства УП является жизненный цикл. Стадии жизненного цикла проекта могут назначаться в зависимости от сферы деятельности и принятой системы организации работ. С точки зрения соотношения формализуемой и неформализуемой компонент можно выделить следующие стадии ЖЦ:

начальная стадия (формулирование проекта;

стадия реализации проекта (планирование, осуществление) стадия завершения проекта.

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

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

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

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

4. выявление потребности в изменениях (проекте);

5. определение проекта;

6. определение и сравнительная оценка альтернатив, принятие основных концептуальных решений;

7. разработка предварительного плана проекта;

8. утверждение предварительного плана проекта и получение одобрения на продолжение работ.

Прокомментируем некоторые пункты этого списка.

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

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

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

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

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

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

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

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

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

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

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

Организация выполнения работ.

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

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

Формальное и детальное планирование (на базе предварительного плана).

Детальное проектирование и технические спецификации.

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

Установление системы информационного контроля за ходом работ.

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

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

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

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

Подтверждение окончания работ и получение одобрения для работ следующей стадии.

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

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

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

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

Стадия завершения проекта. Конкретный характер мероприятий, завершающих проект, зависит от характера самого проекта, например:

эксплуатационные испытания окончательного продукта проекта;

подготовка кадров заказчика для эксплуатации создаваемого объекта;

сдача объекта заказчику и ввод в эксплуатацию;

защита проекта;

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

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

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

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

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

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

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

Основой для структурирования проекта является структура декомпозиции работ (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 для таких проектов можно описать в процессе их реализации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Может ли для части пакета работ отдельно пересчитываться расписание?

Содержит ли пакет работ понятную и полную информацию с точки зрения Проектировщика (планировщика), Исполнителя и Заказчика?

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

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

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

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

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

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

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

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

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

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

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

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

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

Это еще одна причина того, что программирование всегда включает элемент творчества.

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

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

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

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

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

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

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

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

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

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

Неопределенности среды бизнес-процесса, для которого разрабатывается ППП.

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

формирование WBS при большой неопределенности, присущей началу проекта, занимает очень много времени с низким качеством результата;

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

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

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

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

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

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

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

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

объектные модели.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

по системному уровню описания;

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

Так, по системному уровню описания можно выделить:

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

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

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

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

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

В соответствии с [Gartner], архитектура – это:

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

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

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

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

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

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

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

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

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

В делом можно предложить следующее соотношение:

Архитектура предприятия (корпоративная архитектура) = + корпоративная информационно-технологиче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. архитектура отдельных решений и систем – технологии предприятия в целом, планирование систем, структура решений, архитектура программных систем;

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

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

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

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

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

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

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

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

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

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

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

Таблица 1. Наименование Задаваемые концепты домена Бизнес- Связи между бизнес-процессами архитектура Бизнес-функции Архитектура Описание источников данных информации Модели данных Описание решений по организации хранения данных Используемые технологии и средства для преобразования Архитектура Перечень приложений приложений Точки доступа к приложениям Технологическая Инфраструктура архитектура Платформы Для описания динамики развития архитектуры предприятия также возможны два структурирования:

последовательность этапов жизненного цикла (life cycle);

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

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

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

Таблица 1.2.

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

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

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

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

получение данных (из внутренних и внешних источников);

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

хранение и извлечение данных;

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

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

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

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

На логическом уровне абстракции эти процессы конкретизируются до решения следующих вопросов [Данилин, Слюсаренко]:

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

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

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

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

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

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

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

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

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

описание существующих источников данных;

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

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

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

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

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

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

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

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

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

разработка прикладных систем.

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

выделить и кластеризовать ключевые бизнес-процессы;

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

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

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

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

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

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

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

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

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

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

Программное обеспечение промежуточного слоя (middleware).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Миссия и видение.

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

Цели, задачи и стратегии.

Архитектура информационных технологий.

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

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

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

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

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

Рис. 1.7. Соотношение компонентов целеполагания в ИТ-проекте Компоненты целеполагания могут формулироваться для отдельных доменов пространства управления проектом. Например, ниже представлены примеры формулировки принципов, которые могут относиться кИТ- архитектуре крупного предприятия или к государственной структуры среднего уровня.

Примеры декларируемых принципов для архитектуры в целом:

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

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

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

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

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

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

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

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

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

Примеры принципов в области управления данными:

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

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

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

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

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

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

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

Будет применяться компонентная разработка информационных систем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

функциональные (организационно-функциональные) модели;

потоковые модели;

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

объектные модели.

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

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

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

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

МОДЕЛИРОВАНИЯ.

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

Рис. 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 Modeling):

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

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

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

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

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

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

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

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

Рис. 1.12. Модель бизнес-процесса в нотации IDEF На рис. 1.13 показан бизнес-процесс, описанный при помощи нотации IDEF3. (Этот процесс представлен в нотации ARIS eEPC на рис. 1.10). Обратим внимание, что В нотации IDEF3, так же как и в нотации ARIS eEPC, используются символы логики, отражающие ветвление процесса.

Рис. 1.13. Модель бизнес-процесса в нотации IDEF В объектно-ориентированной среде информация группируется внутри классов или объектов (инкапсуляцией как данных, так и процессов). Такой способ моделирования применяется в основном не для описания бизнеспроцессов, а для описания определенных аспектов ИТ-систем.

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

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

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

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

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

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

Эта общая схема моделирования процессов может детализироваться.

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

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 году.

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

ЧТО КАК КТО КОГДА ПОЧЕМУ

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

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

среда бизнес-взаимодействия (Business Relationship Grid);

бизнес-процессы и стили бизнес-процессов;

шаблоны;

технологические строительные блоки.

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

Рис. 1.16. Уровни модели архитектуры Gartner Рис. 1.17. Архитектура ИТ в бизнес-контексте Методики 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] была предложена некоммерческим объединением The Open Group, в которое входит ряд ведущих производителей информационных технологий. Основным полем для применения TOGAF является, прежде всего, программная инфраструктура информационной системы (в противоположность таким типам архитектур, как бизнес-архитектура, архитектура данных и приложений). Таким образом, она в наилучшей мере подходит для описания интеграционных компонент, использующихся для поддержки широкого спектра корпоративных приложений, прежде всего, критичных для бизнеса (mission-critical). Последняя версия была существенно расширена за рамки технологической архитектуры и включает бизнесархитектуру, архитектуру данных и архитектуру приложений. Теперь это одна из самых полных методик, которая к тому же доступна бесплатно (лицензируется только коммерческое использование).

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

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

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

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

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

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

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

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

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

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

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

MSF – "Как правильно создавать ИТ-системы?" MSA – "Как правильно создавать технологическую инфраструктуру?" MOF – "Как правильно эксплуатировать технологическую инфраструктуру?" MSM – "Как правильно строить процессы управления технологической инфраструктурой?" Другими словами, каждая из методик ориентирована на свой уровень абстракции (концептуальной, логической и физической архитектур системы):

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

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

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

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

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

Таблица 1.4.

Перспективы (уровни абстракции) Контекст ("пла- Классы биз- Список биз- Список биз- Список мест раснировщик") нес-процессов нес-сущностей – нес-процессов положения бизнеса (группа процесобъектов, важсов, имеющих ных для бизнеса Концептуальный Сценарии ис- Семантиче- РазбиениеМодели бизнесуровень ("владе- пользования ские модели процессов на лец" предприятия) (Use case) Модели свя- сервисы Операционные Логический Модели про- Логические Определе- Логические типы ("проектиров- цессов (потоков модели данных ния сервисов серверов: БД, почщик") работ) Схемы дан- Взаимосвя- товые, транзакциМодели биз- ных зи между сер- онные, … 1.3. Процессы жизненного цикла и методологии их описания 1.3.1. Классификации моделей жизненного цикла разработки ПО Любой проект в процессе своей реализации проходит различные стадии, называемые в совокупности жизненным циклом (ЖЦ) проекта. ЖЦ определяет, что и в какой последовательности должно делаться при создании и эксплуатации системы – от замысла до воплощения (в некоторых случаях – до утилизации и/или замены на новую систему).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

недостаточная гибкость модели;

формальное управление проектом часто становится самоцелью (в ущерб срокам, стоимости и качеству).

Однако она имеет и достоинства:

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

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

разрешены перекрытия фаз;

поддерживаются итеративные методы и создание прототипа.

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