Ответы на 14/15/16/17

18/////////////////////////////////////18//////////////////////////////////////18///////////////////////////////////////18////////////////////////////////////////18

В последние годы мы видим, что ведущие поставщики средств разработки ПО (в первую очередь IBM Rational и Borland) от выпуска отдельных инструментов переходят к созданию комплексных платформ управления жизненным циклом приложений (ALM). Microsoft пока не форсирует процесс формирования полного спектра ALM-решений для автоматизации различных этапов производства ПО, хотя движется именно в этом направлении и основной акцент делает на средствах проектирования и разработки - Visio, Visual Studio и т. д.

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

Посредством пакета руководств (MSF) гигант IT индустрии решил поделиться опытом и накопленной информацией в области проектирования, разработки, внедрения и сопровождения IT -проектов. База знаний MSF состоит из оригинальных моделей, методов и взглядов на такие области знаний как управление проектами, персоналом, планирование, анализ рисков и другие смежные дисциплины. Нельзя сказать, что MSF очередной чисто теоретический взгляд на управление. В руководствах по MSF кроме методов, моделей и концепций встречаются практические советы и приёмы, отнюдь не лишенные рациональности. Структурно пакет руководств MSF разделён на пять документов, так называемых “белых книг”, каждый из которых охватывает определенную дисциплину или модель MSF:

- “Модель процессов MSF”;

- “Модель проектной группы MSF”;

- “Дисциплина управления проектами MSF”;

- “Дисциплина управления рисками MSF”;

- “Дисциплина управления подготовкой MSF”.

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

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

19///////////////////////////19////////////////////////////19////////////////////////////////////////////////19/////////////////////////////////////////////////////////19

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

Как легко заметить, модель MSF предлагает несколько иную разбивку на этапы ЖЦ ПО и их наименование, отличающуюся от общепринятого на сегодняшний день списка ALM-этапов, которого, в частности, придерживаются компании Borland и IBM Rational. Речь здесь не идет просто о разных названиях одних и тех же видов деятельности. Объективная проблема категоризации заключается в том, что выделение самостоятельных этапов в жизненном цикле приложений весьма условно, особенно если речь идет об итерационной циклической модели разработки. Например, широкое использование визуальных методов проектирования с автоматической генерацией кода фактически стирает грань между проектированием и кодированием. А тестирование вообще пронизывает всю жизнь программы. Имеются и субъективные факторы, которые определяются различиями стратегических бизнес-целей разных поставщиков методологий. Именно этим объясняется то, что Microsoft - основу бизнеса которой составляют не средства разработки, а платформенное ПО, - больше внимания (по сравнению с теми же IBM Rational и Borland) уделяет общим вопросам организации процесса создания приложений, а также их внедрению.

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

20//////////////////////////////////////////////////////20///////////////////////////////////////////////////////////20////////////////////////////////////////////////20////////////////////////////////////////////////////20

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

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

1. Управление продуктом

2. Управление программой

3. Разработка

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

5. Удовлетворение потребителя

6. Управление выпуском

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

7. Распределение ответственности при фиксации отчетности;

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

Таким образом, все ролевые кластеры в команде равноправны. Однако иерархия отчётности при этом не нарушается, а остается прежней. Это путь к качественному продукту. Составление календарных планов работ осуществляется руководителем соответствующего ролевого кластера. Это побуждает к большей ответственности за свои сроки и обязательства, чем за те, которые на тебя спустили сверху. Каждый ролевой кластер принимает участие в принятии решений о завершении фаз проекта. Противоречия разрешаются методом компромиссов. Кроме того хорошей практикой является вход в состав группы представителей заказчика, что увеличивает заинтересованность и активное содействие внедрению со стороны заказчика. Кроме того, заказчик становится более информированным о ходе проекта т.к. информация по проекту между кластерами доступна членам команды. Например, если разрабатывается система автоматизации предприятия, хорошей, на мой взгляд, практикой будет назначить руководителем кластера Управление выпуском (по сути, это внедрение и материальное обеспечение внедрения) представителя заказчика, а исполнителями же внедрения - сотрудников компании-исполнителя. В случае успеха слава за удачу (речь идет не о финансовом поощрении) разделится поровну между всеми участниками проекта. А вот ответственность распределена в соответствии с ролевым кластером. Менеджер проекта (ролевой кластер Управление программой) будет отвечать, если проект не уложится в срок и в смету, разработка – если не выполнит разработку в названный ей же срок, тестирование – если в выпущенной версии будут возникать проблемы и т.д. Этап планирования не завершиться пока все ролевые кластеры не будут согласны с планом проекта. Это, конечно, несколько увеличит срок принятия решений, зато многократно уменьшит вероятность ошибочных решений. Однако, по мнению Microsoft, такой подход намного сильнее стимулирует творчество, ответственность, коммуникации и взаимопонимание в проектной группе, чем привычный нам, вид управления самодержца.

Ответы на 18/19/20

17(2)////////////////////////////////////////////////////////////17(2)///////////////////////////////////////////////////////////////////////////////////////////////////17(2)/////////////////////////////17(2)

BPwin является средством, которое позволяет облегчить проведение обследования предприятия и построить функциональные модели. ERwin является системой проектирования баз данных. С 1998 года эти инструментальные средства непрерывно совершенствовались. Логическим завершением этого развития явился выпуск в 2002 году фирмой Computer Associates (CA) интегрального пакета инструментальных средств, поддерживающих все этапы разработки информационных систем - AllFusion Modeling Suite 4.1. В этот пакет входит 5 продуктов:

1. AllFusion Process Modeler 4.1. AllFusion Process Modeler является новым именем хорошо известного BPwin. Вообще говоря, в документации и пресс-релизах СА используются оба наименования - новое AllFusion Process Modeler 4.1 и "старое" BPwin 4.1.

2. AllFusion ERwin Data Modeler 4.1 -инструмент создания моделей данных и генерации схем баз данных. "Старое" название - ERwin 4.1.

3. AllFusion Data Model Validator 4.1 - система поиска и исправления ошибок модели данных. Прежнее название - ERwin Examiner.

4. AllFusion Model Manager 4.1. Система организации коллективной работы, хранилище моделей BPwin и ERwin. "Старое" название - ModelMart 4.1.

5. AllFusion Component Modeler 4.1 - инструмент создания объектных моделей. "Старое" название - Paradigm Plus.

18(2)////////////////////////////////////////////////////////////////////////////////// 18(2)////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// 18(2)

Для проведения анализа и реорганизации бизнес-процессов предназначено CASE-средство верхнего уровня AllFusion Process Modeler (BPwin), поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (модель ТО-ВЕ). Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы: каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования. Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия, как "внешняя ссылка" и "хранилище данных", что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота. Методология IDEF3 включает элемент "перекресток", что позволяет описать логику взаимодействия компонентов системы.

19(2)////////////////////////////////////////////////////////////////////////////////////////////////////////// 19(2)///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// 19(2)

На основе модели BPwin можно построить модель данных. Для построения модели данных Computer Associates предлагает мощный и удобный инструмент - AllFusion ERwin Data Modeler (ERwin). Хотя процесс преобразования модели BPwin в модель данных плохо формализуется и поэтому полностью не автоматизирован, Computer Associates предлагает удобный инструмент для облегчения построения модели данных на основе функциональной модели - механизм двунаправленной связи BPwin - ERwin (стрелка 1 на рис. 1.7). ERwin имеет два уровня представления модели - логический и физический, причем модель данных может содержать как оба этих уровня, так и только один из них. Модели, содержащие только один уровень, могут быть синхронизированы, что особенно удобно при создании гетерогенных информационных систем. На логическом уровне данные не связаны с конкретной СУБД, поэтому могут быть наглядно представлены даже для неспециалистов. Физический уровень данных - это, по существу, отображение системного каталога, который зависит от конкретной реализации СУБД. Создание одного логического уровня и нескольких соответствующих ему физических позволяет вести одновременную разработку баз данных для нескольких СУБД. ERwin позволяет проводить процессы прямого и обратного проектирования баз данных (стрелка 2). Это означает, что по модели данных можно сгенерировать схему базы данных или автоматически создать модель данных на основе информации системного каталога. Кроме того, ERwin позволяет выравнивать модель и содержимое системного каталога после редактирования.

20(2)/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////20(2)

Создание современных ИС, основанных на широком использовании распределенных вычислений, объединении традиционных и новейших информационных технологий, требует тесного взаимодействия всех участников проекта: менеджеров, бизнес-аналитиков и системных аналитиков, администраторов баз данных, разработчиков. Для этого использующиеся на разных этапах и разными специалистами средства моделирования и разработки должны быть объединены общей системой организации совместной работы. Фирма Computer Associates предлагает систему ModelMart - хранилище моделей, к которому открыт доступ для участников проекта создания ИС (стрелка 5 на рис.1.7). ModelMart удовлетворяет всем требованиям, предъявляемым к средствам разработки крупных ИС, а именно:

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

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

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

4. Архитектура ModelMart. ModelMart реализована на архитектуре клиент-сервер. В качестве платформы реализации хранилища выбраны РСУБД Sybase, Microsoft SQL Server, Informix и Oracle. Клиентскими приложениями являются ERwin и BPwin. В ModelMart реализован доступ к хранилищу моделей через API, что позволяет постоянно наращивать возможности интегрированной среды путем включения новых инструментов моделирования и анализа.

21//////////////////////////////////////////////////////////////////////21///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////21

Для больших, содержащих сотни таблиц моделей данных существенной проблемой становится поиск и исправление ошибок. Решение этой проблемы вручную - слишком трудоемкая задача, которая может недопустимо затянуть выполнение проекта. AllFusion Data Model Validator (ERwin Examiner) - основанный на базе знаний инструмент, который позволяет анализировать структуру баз данных с целью выявления недочетов и ошибок проектирования. ERwin Examiner дополняет функциональность ERwin, автоматизируя трудоемкую задачу поиска и исправления ошибок. ERwin Examiner может использовать в качестве источника метаданных готовую модель ERwin, DDL-скрипт или провести обратное проектирование базы данных (стрелки 3 и 4).

При проектировании больших ИС ключевой проблемой является создание качественной документации по моделям. BPwin и ERwin позволяют генерировать разнообразные отчеты, которые могут быть использованы для анализа и документирования моделей. Отчеты могут быть экспортированы в распространенные форматы - текстовый, MS Office, HTML и др. Результаты экспорта могут быть использованы для создания отчетов с помощью средств других производителей, например Crystal Reports. BPwin поддерживает также экспорт и импорт модели в текстовый файл формата IDL, который является стандартом для экспорта и импорта моделей IDEF0, позволяет разрабатывать функциональные модели одновременно инструментальными средствами различных производителей.

Как было указано выше (см. п. 3), при разработке крупных проектов критическим становится время реализации проекта. Одним из решений проблемы может стать автоматическая генерация кода приложения CASE-средствами на основе модели предметной области. Эту задачу решает технология кодогенерации, основанная на объектно-ориентированном проектировании. Существует несколько CASE-средств, поддерживающих языки объектно-ориентированного проектирования, в том числе ставший в последнее время стандартом UML. Одним из них является AllFusion Component Modeler (Paradigm Plus). Этот инструмент позволяет строить объектные модели и генерировать на основе полученной модели приложения на языках программирования C++, Visual Basic, Java и др. Поскольку генерация кода реализована на основе знаний предметной области, полученный код адекватно отражает бизнес-логику. Paradigm Plus поддерживают не только прямую генерацию кода, но и обратное проектирование, т. е. создание объектной модели по исходному коду приложения. Возможно также преобразование объектной модели Paradigm Plus в модель данных ERwin и обратно.

Ответы на 17(2)/18(2)/19(2)/20(2)/21

22//////////////////////////////////////////////////////////////////////22////////////////////////////////////////////////////////////////////////////22////////////////////////////////////////////////////////////////22

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

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

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

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

23////////////////////////////////////////////////////////////////////////////////////////////////23////////////////////////////////////////////////////////////////////////////////////////////////////23