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

Работа из раздела: «Программирование, компьютеры и кибернетика»

Содержание

Введение
1. Современные методологические проблемы разработки и внедрения программного обеспечения ERP систем
1.1 Философия программного обеспечения
1.2 Основные концептуальные подходы к методологии разработки и внедрения программного обеспечения
1.3 Классификация методологий разработки и внедрения программного обеспечения
Вывод
2. Исследование методологии ASAP: ее сильные и слабые стороны
2.1 Общее описание методологии ASAP
2.2 Сильные и слабые стороны методологии ASAP
2.3 Возможные пути решения современных проблем внедрения ERP систем с использованием методологии ASAP на отечественных предприятиях
Вывод
3. Описание эксперимента по переносу дорожной карты ASAP в инструментальную среду методологической платформы RUP
3.1 Концепция и нотация моделирования
3.2 Инструментальное средство моделирования
3.3 Формализованное описание процесса внедрения ERP систем SAP на отечественных предприятиях
Вывод
Заключение
Список использованной литературы

Введение

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

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

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

Не смотря на то, что рынок ERP систем начал развиваться в нашей стране относительно недавно, на нем успели появиться свои лидеры - наиболее популярные у нас в стране ERP системы. Одной из таких наиболее популярных систем является система mySAP ERP 2005 SR2 - один из новейших продуктов известной во всем мире немецкой компании SAP AG. Интересно отметить, что ERP системы SAP, как и прочие продукты этой компании, поставляются вместе с собственной методологией их внедрения. Эта методология называется AcceleratedSAP (ASAP). Сам факт наличия методологии, специально разработанной компанией-производителем ERP системы для ее внедрения, вызывает интерес. Поэтому именно эта методология в данной аттестационной работе является объектом изучения методологических проблем внедрения ERP систем на отечественных предприятиях.

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

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

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

· Что является источником этих проблем?

· Как подойти к разработке и внедрению ERP систем, минуя эти проблемы?

· Какой должна быть избавляющая от проблем методология разработки и внедрения ERP систем?

Чтобы получить ответы на эти вопросы, необходимо решить ряд задач:

· Раскрыть сущность программного обеспечения: что это такое, кто его создает и как;

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

· Классифицировать и сопоставить основные методологии, выбрать из них наиболее подходящую для внедрения ERP систем;

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

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

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

1. Современные методологические проблемы разработки и внедрения программного обеспечения ERP систем

1.1 Философия программного обеспечения

Философия одного века - это здравый смысл следующего (Генри Уорд Бичер).

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

· ЧТО создается и внедряется в качестве программного обеспечения?

· КАК создается и внедряется программное обеспечение?

· КТО создает и внедряет программное обеспечение?

К сожалению, в третьей четверти XX века, когда закладывались основы разработки и внедрения программного обеспечения, как в нашей стране, так и во всем мире, различные книгоиздательства уделяли очень мало внимания такого рода вопросам. Их обсуждение проводилось в основном в узких кругах: в отдельных проектных группах крупных компаний, на кафедрах университетов, в военных лабораториях. Со временем, обсуждение проблем разработки и внедрения стало производиться в периодической печати в виде статей и очерков. Одного из авторов наиболее известных очерков о проблемах разработки и внедрения программного обеспечения, доктора Фредерика Брукса (Frederick Brooks), без сомнения можно назвать современным философом.

Фредерик Брукс - профессор вычислительной техники в школе бизнеса Кенан университета штата Северная Каролина в Чэпел Хилл, США. Он известен, прежде всего, как 'отец IBM System/360'. Помимо этого, Брукс работал в IBM над архитектурой компьютеров Stretch и Harvest. Его сборник очерков 'Мистический человеко-месяц или как создаются программные системы', впервые опубликованный в 1975 году, не утратил своей популярности и переиздается до сих пор. Причина его актуальности на протяжении более 30 лет бурного развития технологий аппаратного и программного обеспечения заключается в том, что доктор Брукс освещает не только вопросы технологии. Главное в его работах - анализ самой природы программного обеспечения, его 'сущности и акциденции', а также проблем, связанных с его разработкой и внедрением.

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

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

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

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

Системный программный продукт

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

Почему же до сих пор все профессиональные команды программистов не заменены одержимыми дуэтами из гаражей? Нужно посмотреть на то, ЧТО собственно производится!

Эволюция системного программного продукта представлена Бруксом в виде диаграммы (рис.1):

Рисунок 1. Эволюция системного программного продукта

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

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

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

Чтобы стать общеупотребительным программным продуктом, программа должна быть написана в обобщенном стиле. В частности, диапазон и вид входных данных должны быть настолько обобщенными, насколько это допускается базовым алгоритмом. Примером может являться общепринятый стиль приложений MDI (multiple document interface), в котором выполнены программные пакеты Microsoft Office. Трудно себе представить современное бизнес-приложение, имеющее какой либо революционный интерфейс для общения с пользователем, не использующий стандартных окон и линеек прокрутки, предоставляемых операционными системами семейства Windows через интерфейс API (application programming interface), или не имитирующий его.

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

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

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

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

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

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

Завершая обсуждение 'Системного программного продукта', необходимо отметить его наиважнейшую характеристику - концептуальное единство (целостность).

Концептуальная целостность архитектуры программного обеспечения, особенно если речь идет о больших системах, даже более важна, чем целостность архитектуры зданий. У большинства европейских средневековых соборов части, построенные разными поколениями строителей, имеют существенные различия в планировке и архитектурном стиле. Более поздние строители испытывали соблазн 'улучшить' проект своих предшественников, чтобы отразить новые веяния моды и свои личные вкусы. Ярким, достойным восхищения, примером соблюдения архитектурного единства в противоположность распространенному смешению стилей является Реймский собор во Франции. Целостность архитектуры была достигнута благодаря самоотречению восьми поколений строителей собора, пожертвовавших своими идеями ради чистоты общего замысла.

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

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

· вытекающие из сущности программного объекта - внутренние, присущие природе программного обеспечения;

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

Сущность программного обеспечения

Сущностью программного объекта по Бруксу является конструкция, состоящая из сплетенных вместе концепций:

· наборов данных;

· взаимосвязей между элементами данных;

· алгоритмов;

· вызовов функций.

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

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

программное обеспечение методология внедрение

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

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

Сложность

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

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

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

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

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

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

Согласованность

Люди, связанные с разработкой и внедрением программного обеспечения не одиноки в проблемах сложности. Физика имеет дело с объектами чрезвычайной сложности даже на уровне элементарных частиц. Но физик работает в твердой уверенности, что всему есть рациональное объяснение. Альберт Эйнштейн утверждал, что '… природа должна иметь простые объяснения, поскольку Богу не свойственны капризность и произвол …'.

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

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

Изменяемость

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

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

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

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

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

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

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

Незримость

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

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

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

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

Как создавать большие программные системы в разумные сроки?

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

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

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

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

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

Рассмотрим подробнее перечисленные аспекты данной проблемы:

Во-первых, Оптимизм

Итак, первый краеугольный камень проблемы - излишний оптимизм. Все разработчики программного обеспечения - оптимисты. Сколько раз в течение часа можно услышать от одного и того же программиста: 'На этот раз она точно пойдет!' или 'Я только что выявил последнюю ошибку!'.

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

Глубокий оптимизм разработчиков заслуживает отдельного изучения. Дороти Сэйерс (Dorothy Sayers) в своей книге 'Разум творца' ('The Mind of the Maker') выделяет в творческой деятельности три стадии:

1. Замысел;

2. Реализация;

3. Взаимодействие.

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

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

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

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

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

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

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

Во-вторых, Человеко-месяц

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

'… использование человеко-месяца как единицы измерения объема работы является опасным заблуждением …' (Ф. Брукс)

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

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

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

Рисунок 3. Зависимость времени от числа занятых - неразделимая задача

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

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

Рисунок 4. Зависимость времени от числа занятых - разделимая задача, требующая обмена данными

Дополнительная нагрузка состоит из двух частей:

· обучение;

· обмен данными.

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

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

Таблица 1. Зависимость количества каналов попарного общения от количества занятых

Количество занятых	Количество каналов попарного общения
2	1
3	3
4	6
5	10
6	15
7	21
8	28
9	36
10	45
11	55

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

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

Рисунок 5. Зависимость времени от числа занятых - задача со сложными взаимосвязями

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

В-третьих, Робость в оценках

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

· ждать еще;

· съесть омлет сырым.

Тот же выбор стоит и перед заказчиком программного обеспечения.

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

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

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

В-четвертых, Тушим пламя бензином

Что делают, когда важный программный проект начинает отставать от графика? Естественно, добавляют людей. Как рассмотрено ранее и отображено на рисунках 2 - 5, это не всегда помогает. В случае разработки и внедрения больших ERP систем, ситуация в большинстве случаев складывается, как на рисунке 5.

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

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

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

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

Итак, рассмотрев, чего нужно опасаться и чего делать не стоит при разработке и внедрении программного обеспечения, перейдем к поиску ответа на вопрос: 'КАК следует это делать?'.

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

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

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

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

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

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

Операционная бригада

Известный американский ученый в области компьютерной техники и программного обеспечения, посвятивший множество работ методикам его разработки и внедрения, Харлан Миллз в 1971 году в своем докладе 'Chief programmer teams, principles, and procedures' высказал революционную в то время идею, которая заключалась в следующем. Рассмотренное выше противоречие можно разрешить путем формирования достаточного для большой системы количества обособленных малых (около 10 человек) производительных и активных команд наподобие хирургической бригады. Общий проект должен разбиваться на крупные минимально связанные задачи, целиком поручаемые той или иной бригаде. При этом не каждый участник бригады будет врезаться в задачу, но резать будет один (Хирург), а остальные оказывать ему всевозможную поддержку, повышая его производительность и плодотворность. При такой организации немного голов заняты проектированием и разработкой, и в тоже время множество сотрудников работают 'на подхвате'. Будет ли такая организация работать? Кто играет роль анестезиологов и операционных сестер в группе разработчиков и как осуществляется разделение труда? Миллз делит свою бригаду на следующие роли:

Хирург

В докладе Миллза автор называет эту роль 'Главный программист' (Chief programmer).

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

Второй Хирург

Это второе 'я' Хирурга.

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

Администратор

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

Редактор

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

Два секретаря

Администратору и Редактору нужны Секретари.

Секретарь Администратора обрабатывает переписку, связанную с проектом, а также документы, не относящиеся к продукту.

Секретарь Редактора обрабатывает документацию по разрабатываемому и внедряемому продукту.

Делопроизводитель

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

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

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

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

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

Инструментальщик

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

Отладчик

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

Языковед

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

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

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

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

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

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

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

Рисунок 6. Каналы попарного общения в операционной бригаде из 10 человек

Максимально возможное количество попарных контактов при такой организации 10 человек равно 13, тогда как при обычной организации - 45 (таб.1). Кроме того, при совместной работе нескольких операционных бригад будут организованы контакты только между Хирургами, что на порядки сократит количество каналов попарного общения и увеличит производительность в больших проектах.

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

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

· Существенное (на порядки) сокращение взаимосвязей между задачами и разработчиками.

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

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

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

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

· Методологии управления процессами;

· Методологии оценки процессов.

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

Модель Водопада (каскадная)

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

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

Рисунок 7. Модель процесса 'Кодирование - устранение ошибок'

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

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

Рисунок 8. Каскадная модель (модификация с обратной связью)

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

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

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

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

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

Преимущества каскадной модели:

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

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

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

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

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

· она отличается стабильностью требований;

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

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

· она способствует осуществлению строгого контроля менеджмента проекта;

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

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

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

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

· стадии модели довольно хорошо определены и понятны;

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

Недостатки каскадной модели:

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

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

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

· она может создать ошибочное впечатление о работе над проектом: показатель суммарной задачи на диаграмме Гантта с отслеживанием '35% выполнено' не отображает реального прогресса разработки и внедрения программного обеспечения и не несет менеджеру проекта почти никакой смысловой информации;

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

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

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

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

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

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

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

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

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

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

Фредерик Брукс во втором издании своего классического труда “'Мистический человеко-месяц или как создаются программные системы' так описывает главную беду каскадной модели:

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

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

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

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

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

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

Модель Быстрого прототипирования

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

Доктор Брукс в своем очерке 'Планируйте на выброс' писал:

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

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

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

В своей более поздней работе 'Серебряной пули нет - сущность и акциденция в программной инженерии' доктор Брукс отметил положительные моменты в применении методов быстрого прототипирования:

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

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

Он также отметил, что:

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

Уоттс Хэмфри (Watts Humphrey), который известен как вдохновитель создания методологии SEI CMM поддерживает Брукса в его подходе к важности требований и их определения:

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

Согласно Джону Коннэлу (John Connel) и Линде Шафер (Linda Shafer), эволюционным ускоренным прототипированием является '…легко поддающаяся модификации и расширению рабочая модель предполагаемой системы, не обязательно представляющая собой все свойства системы, благодаря которой пользователи данного продукта получают физическое представление о ключевых частях системы до ее непосредственной реализации; это - легко создаваемая, без труда поддающаяся модификации, максимально расширяемая, частично заданная рабочая модель основных аспектов предполагаемой системы…'

Бернард Боар (Bernard Boar) определил прототип как '…метод, предназначенный для определения требований, при котором потребности пользователя извлекаются, представляются и разрабатываются посредством построения рабочей модели конечной системы - быстро и в требуемом контексте…'

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

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

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

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

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

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

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

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

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

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

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

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

· возможность возникновения разногласий при общении пользователей с разработчиками минимизирована;

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

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

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

· обеспечивается управление рисками;

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

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

Недостатки модели быстрого прототипирования:

· модель может быть отклонена из-за создавшегося среди консерваторов мнения о ней, как о методе 'разработки на скорую руку';

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

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

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

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

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

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

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

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

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

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

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

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

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

· требования не известны заранее;

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

· следует уточнить требования;

· существует потребность в разработке пользовательских интерфейсов;

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

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

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

· алгоритмы или системные интерфейсы усложнены;

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

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

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

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

Инкрементная модель

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

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

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

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

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

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

Преимущества инкрементной модели:

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

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

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

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

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

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

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

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

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

· снижается риск неудач при изменениях требований;

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

· клиент может привыкать к новой системе постепенно;

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

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

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

Недостатки инкрементной модели:

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

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

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

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

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

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

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

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

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

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

· однопроходная разработка системы связана с большой степенью риска;

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

Спиральная модель

В спиральной модели, впервые представленной доктором Барри Боемом (Barry Boehm) и опубликованной в журнале IEEE Computer в 1988 году, учтены недостатки каскадной модели.

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

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

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

Рисунок 9. Спиральная модель

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

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

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

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

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

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

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

Первая версия и первоначальная пригодность для эксплуатации (Initial Operational Capability, IOC) - это первый шанс клиента на тестирование системы, после чего следует другой набор действий по планированию, ведущий к следующей итерации. Версия, получаемая в результате проведения клиентом приемочных испытаний, сдается перед наступлением стадии конечной пригодности для эксплуатации (Final Operational Capability, FOC), то есть точно так же, как это происходит в каскадной модели.

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

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

Преимущества спиральной модели:

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки спиральной модели:

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

· модель имеет усложненную структуру, поэтому может быть затруднено ее применение разработчиками, менеджерами и клиентами;

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

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

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

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

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

· организация обладает навыками адаптации модели;

· проект сопряжен со средней или высокой степенью риска;

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

· пользователи не уверены в своих потребностях;

· требования очень сложные;

· разрабатываются новые функции;

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

· проект большой;

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

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

· нет уверенности в достижении проектом успеха;

· необходима демонстрация качества и возможности достижения целей в короткий период времени;

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

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

Известный английский ученый, автор ряда книг и статей об архитектуре программного обеспечения, объектно-ориентированному анализу и разработке, языку UML, рефакторингу, экстремальному программированию, Мартин Фаулер (Martin Fowler) в своей книге 'UML. Основы. Краткое руководство по стандартному языку объектного моделирования' писал:

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

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

· итеративный подход;

· каскадный подход.

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

При каскадном подходе используется классическая декомпозиция в соответствии со 'Сводом знаний по управлению проектами' (PMBoK). При этом за основу декомпозиции берется, как правило, 'структурная декомпозиция работ (СДР.)' (work breakdown structure (WBS)). При этом деление является линейно-структурным, то есть классическая структурная декомпозиция работ последовательно проецируется на график проекта, образуя так называемый 'критический путь' выполнения проекта. При этом прогресс выполнения проекта оценивается как % от выполнения суммарной задачи, что далеко не всегда соответствует прогрессу создания конечного продукта. Важно, что для каскадного подхода характерным является поздние (на заключительных фазах) интеграция и тестирование продукта.

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

Рисунок 10. Итеративный подход к разработке и внедрению программного обеспечения

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

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

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

1.3 Классификация методологий разработки и внедрения программного обеспечения

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

Наряду с качественной классификацией, необходимо также классифицировать методологии и по количественному показателю. Сколько методологии должно быть в процессе: насколько он должен управляться формализованными процедурами, а на сколько должен опираться на свободное творчество и оригинальные идеи членов команды разработчиков. Элистер Кокберн (Alistair Cockburn) называет этот количественный показатель 'методологический вес'. Параметр количественной классификации, выраженный этим показателем также имеет два полюса: высокая/низкая формализованность. При низкой формализованности производится минимум служебной документации, а процесс характеризуется минимумом формализма. При высокой формализованности служебная документация полна, поддерживается соответствие друг другу элементов процесса (трассируемость), управление изменениями, и т.д.

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

Рисунок 11. Карта процессов

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

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

Гибкая разработка стала очень популярной, особенно среди небольших команд разработчиков, и эта популярность продолжает расти. Это огромное семейство методологий, к которому можно отнести такие известные методологии, как экстремальное программирование (eXtreme Programming, XP), Scrum, группа методологий Crystal, и др.

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

Популярность гибких методологий разработки выросла относительно недавно - в конце 90-х годов прошлого века, но они изначально основаны на лучшем практическом опыте (best practice), который существует уже многие годы, в частности:

· на итеративной разработке;

· непрерывной интеграции;

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

· на регулярной переработке кода;

· на использовании стандартов кодирования;

· на информации от пользователей (обратной связи);

· и т.д.

Движение 'За гибкую разработку' за последние десятилетия проделало огромную работу по поддержке и популяризации этих лучших практических методов и предложило свои собственные, такие как парное программирование (pair programming) и разработка 'тестами вперед' (test-first design).

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

Рисунок 12. Методологии гибкой разработки на Карте процессов

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

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

SEI CMM, SEI CMMI, DOD-STD, MIL-STD:

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

Параллельно с движением 'За гибкую разработку' существует тенденция к более формализованному подходу к разработке и внедрению программного обеспечения. К этому подходу относятся как методологии оценки процессов (SEI CMM, SEI CMMI, и др.), так и методологии управления процессами разработки и внедрения программного обеспечения (DOD-STD, MIL-STD, и др.).

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

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

SEI CMM: методология оценки процессов

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

Модель уровня зрелости (Capability Maturity Model, CMM) процесса разработки и внедрения программного обеспечения, созданная в Институте Программной Инженерии (Software Engineering Institute, SEI) в США, разработана специально для этой цели. CMM - это средство оценки, используемое для определения уровня зрелости используемой методологии управления процессом разработки и внедрения программного обеспечения по пятибалльной шкале. CMM не предназначена для разработки и внедрения программного обеспечения, для этого необходима методология управления процессом, например RUP, XP или MIL-STD-498.

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

SEI CMMI: методология оценки процессов

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

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

Рисунок 13. Формализованные методологии оценки процессов на Карте процессов

DOD-STD и MIL-STD: высокоформализованные процессы

Характерным примером методологий, использующих высокоформализованный подход к разработке и внедрению программного обеспечения, являются такие специфические процессы, как DOD-STD-2167, DOD-STD-2167A, MIL-STD-1521B и MIL-STD-498 (рис.14):

Рисунок 14. Формализованные методологии управления процессами разработки на Карте процессов

Все эти методологии являются стандартами Министерства обороны Соединенных Штатов Америки. Все они склоняют разработчиков к высокоформализованному подходу. В этих стандартах акцент делается на последовательность высокоформализованных рецензий (рецензия требований, предварительная рецензия дизайна, критическая рецензия дизайна, и т.д.), делать которые настолько дорого, что все, кроме каскадного подхода, оказывается непрактичным. Исключение составляет лишь MIL-STD-498, в котором подчеркивается, что разработчики должны создавать только те элементы процесса, которые действительно необходимы для конкретного проекта разработки и внедрения программного обеспечения. Этот стандарт несколько более открыт для использования итеративной разработки, но все же не идет достаточно далеко.

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

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

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

Именно такую комплексную методологию 'Rational Unified Process' (RUP), вобравшую в себя различные подходы и лучший опыт разработки и внедрения программного обеспечения, предложила компания Rational Software, входящая в настоящее время в состав IBM.

Первое, что бы хотелось отметить, RUP - это открытая методология, доступная любому физическому или юридическому лицу бесплатно после регистрации на сайте компании IBM в виде off-line сайта. Бесплатная версия RUP доступна в нескольких полнофункциональных конфигурациях, как на оригинальном (английском), так и на различных языках, в том числе русском. При написании данной работы использовались русская и оригинальная (английская) конфигурации RUP версии 7.2.0 для больших проектов.

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

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

Рисунок 15. Конфигурации RUP на Карте процессов

На мой взгляд, методология RUP - наиболее подходящий выбор для разработки и внедрения программного обеспечения вообще и ERP систем в частности. Она располагается именно в той области карты процессов, которая отвечает современным требованиям разработки и внедрения программного обеспечения: ориентация на итеративный подход и вариантность 'методологического веса'.

Вывод

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

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

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

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

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

В следующей главе мы рассмотрим методологию, разработанную производителем для внедрения наиболее популярной в нашей стране ERP системы компании SAP AG, определим ее место на карте процессов и сопоставим с проведенными исследованиями.

2. Исследование методологии ASAP: ее сильные и слабые стороны

2.1 Общее описание методологии ASAP

Методология AcceleratedSAP (ASAP) представляет собой 'дорожную карту' (Roadmap), представляющую проект внедрения в виде пути через пять основных фаз (рис.16):

Рисунок 16. Маршрутная карта ASAP

Маршрутная карта ASAP была разработана для поддержки усилий проектных команд, направленных на планирование, управление и завершение проектов на всем протяжении внедрения и эксплуатации решений SAP.

Дорожная карта внедрения состоит из пяти фаз:

1. Project Preparation (Подготовка проекта): проект формально инициирован и планирование идет полным ходом;

2. Business Blueprint (Концептуальный Проект): проектная команда собирает требования и производит концептуальное проектирование решения;

3. Realization (Реализация): решение построено и его интеграция протестирована; тестирование производительности планируется;

4. Final Preparation (Заключительная Подготовка): конечные пользователи обучены; это окончательная проверка перед переходом на новое системное решение;

5. Go Live and Support (Выпуск и Поддержка): решение получило одобрение, началась непрерывная поддержка. Проект завершен.

Каждая фаза, как показано на рисунке 16, визуализируется в разрезе областей знаний (knowledge areas) проекта внедрения. В рамках каждой отдельной области знаний выполняются группы работ (deliverable group), состоящие из отдельных работ (deliverable), которые порождают на выходе (output) результат, который чаще всего представляет собой какой-либо рабочий документ или документы, называемые в терминологии ASAP акселераторами (accelerators). Именно ориентированность методологии ASAP на создание большого количества документации (accelerators) и дала ей название 'AcceleratedSAP'.

Дорожная карта ASAP ограничено доступна для загрузки и просмотра в режиме off-line в формате html только на английском языке (рис.17):

Рисунок 17. Off-line версия ASAP

Доступ к ней разрешен только компаниям клиентам и партнерам SAP AG после авторизации в закрытой web-зоне (http://service. sap.com/asap). Кроме того, она интегрирована в инструмент SAP Solution Manager, поставляемый бесплатно с любым приобретенным коммерческим продуктом SAP.

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

Функциональность современной версии SAP Solution Manager (4.0 и выше) значительно шире, чем просто поддержка процесса внедрения системы и не входит в предметную область данной работы. Однако необходимо отметить, что на практике данный инструмент представляет собой многоуровневое приложение, более сложное в использовании и эксплуатации, и более требовательное к ресурсам (особенно аппаратным), чем сама ERP система SAP!!! Этот факт ставит под сомнение целесообразность использования такого 'инструмента' для улучшения процесса внедрения ERP системы, но компания SAP, начиная с версии mySAP ERP 2005 SR2, сделала полноценное внедрение своей ERP системы без SAP Solution Manager невозможным. Также, недоступными без SAP Solution Manager стали любые обновления продуктов SAP, выпущенные после апреля 2007 года.

На мой взгляд, сегодня SAP Solution Manager является не инструментом-помощником, которым можно при желании воспользоваться для ускорения и повышения качества внедрения ERP систем SAP, а тяжелой и дорогостоящей обузой, навязываемой компанией SAP всем своим клиентам и, следовательно, партнерам-интеграторам.

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

· Первый уровень делит дорожную карту на пять вышеперечисленных фаз;

· Второй уровень разбивает каждую фазу на группы работ, названия которых начинаются с префикса DG (deliverable group);

· Внутри групп, на третьем уровне, располагаются работы (deliverable);

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

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

· Accelerators: на этой вкладке расположены ссылки на поставляемые в составе ASAP в формате MS Office акселераторы, соответствующие данному пункту древовидного меню;

· Roles: на этой вкладке расположены ссылки на поставляемые в составе ASAP в формате MS Office описания ролей, предусмотренных методологией ASAP для выполнения той или иной работы, группы работ или создания какого-либо выхода (output);

· Subject areas: на этой вкладке расположены ссылки на поставляемые в составе ASAP в формате MS Office описания областей знаний, необходимые для контекстного восприятия акселераторов и ролей;

· References: на этой вкладке расположены ссылки на прочие ресурсы.

Итак, рассмотрев внешнее представление методологии ASAP, перейдем к ее содержимому.

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

Кратко рассмотрим каждую из пяти фаз, используя материалы самой дорожной карты:

1. Подготовка Проекта (Project Preparation)

Назначение

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

Рисунок 18. Маршрутная карта фазы 'Подготовка проекта'

Интеграция

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

· Определение целей проекта, ориентированных на корпоративные стратегические цели;

· Прояснения границ внедрения и определение стратегии внедрения;

· Определение общего графика проекта и последовательности внедрения;

· Инициация подходящих для проекта стандартов и процедур;

· Утверждение организации проекта и его управляющих органов;

· Распределение ресурсов.

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

2. Концептуальный Проект (Business Blueprint)

Рисунок 19. Маршрутная карта фазы 'Концептуальное проектирование'

Назначение

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

Интеграция

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

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

· Уточнение изначальных целей проекта;

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

· Уточнение общего графика проекта и последовательности внедрения;

· Уточнение технического проекта решения.

Необходимо особо отметить, что фаза оканчивается в разрезе всех областей знаний проекта внедрения созданием единого концептуального проекта (Business Blueprint), который по окончании фазы 'замораживается' и в дальнейшем пересмотру не подлежит (рис. 19). В этом месте особенно ярко проявляется строгая каскадная модель, заложенная в основу ASAP.

3. Реализация (Realization)

Рисунок 20. Маршрутная карта фазы 'Реализация'

Назначение

Назначение фазы реализации - это реализовать в программном обеспечении требования бизнес процессов, основываясь на концептуальном проекте (Business Blueprint). Целью фазы являются окончательная реализация в системе, всеобщее тестирование и выпуск системы в качестве продукта. В дополнение, проектная команда получает соответствующие знания.

Интеграция

В течение этой фазы также выполняются следующие действия:

· Совершенствуется управление организационными изменениями;

· Определяется стратегия перехода на новую систему и передачи решения;

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

Система конфигурируется двумя блоками работ:

· Основной (в пределах наиболее важных);

· Окончательный (оставшиеся).

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

4. Заключительная Подготовка (Final Preparation)

Рисунок 21. Маршрутная карта фазы 'Окончательная подготовка'

Назначение

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

В течение этой фазы также выполняются следующие действия:

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

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

5. Выпуск и Поддержка (Go Live and Support)

Назначение

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

1. Окончание проекта

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

2. Дальнейшее совершенствование

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

Рисунок 22. Маршрутная карта фазы 'Запуск и обслуживание'

В течение этой фазы также выполняются следующие действия:

· Достигается окончательная приемка заказчиком;

· Выполняется закрытие проекта.

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

Рисунок 23. Методология AcceleratedSAP на Карте процессов.

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

Итак, кратко описав методологию AcceleratedSAP, классифицировав ее и сопоставив с проведенными исследованиями с помощью карты процессов, перейдем к исследованию ее сильных и слабых сторон.

2.2 Сильные и слабые стороны методологии ASAP

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

Наследуемые преимущества ASAP:

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

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

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

· она способствует осуществлению строгого контроля менеджмента проекта;

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

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

· стадии модели довольно хорошо определены и понятны;

Наследуемые недостатки ASAP:

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

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

· она может создать ошибочное впечатление о работе над проектом: показатель суммарной задачи на диаграмме Гантта с отслеживанием '35% выполнено' или перемещение маркера по ветвям дерева в левой панели ASAP не отображают реального прогресса разработки и внедрения программного обеспечения и не несут менеджеру проекта почти никакой смысловой информации;

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

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

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

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

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

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

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

· все требования к будущему продукту должны быть известны в начале процесса разработки и внедрения программного обеспечения, но клиенты редко могут исчерпывающе сформулировать все четко заданные требования на ранних фазах разработки. Методология ASAP не рассчитана на динамические изменения в требованиях на протяжении всего процесса, так как получаемые данные 'замораживаются'. Использование методологии может повлечь за собой значительные затраты, если требования в недостаточной мере известны или подвержены динамическим изменениям во время протекания процесса разработки и внедрения, что очень характерно для внедрения ERP систем на отечественных предприятиях;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процедура

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

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

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

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

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

Результат

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· Связанные с применением каскадного подхода к процессу внедрения;

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

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

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

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

o в сторону вариантности формализованности (как высокой, так и низкой);

· Усиление методологии инструментарием, в котором как минимум:

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

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

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

Рассмотрим отдельно каждое из направлений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

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

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

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

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

3. Описание эксперимента по переносу дорожной карты ASAP в инструментальную среду методологической платформы RUP

3.1 Концепция и нотация моделирования

В основу концепции переноса методологии ASAP на методологическую платформу RUP легла заложенная в эту платформу Архитектура Унифицированного Метода UMA (Unified Method Architecture).

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

Метамодель UMA была создана в целях унификации различных методик и языков моделирования процессов, включая расширения SPEM для UML, языки RUP v2003, Unified Process, IBM Global Services Method и IBM Rational Summit Ascendant. Метамодель представляет собой единообразную расширяемую реализацию всех концепций и возможностей вышеперечисленных систем, которой можно описать любую модель из любой из этих систем (рис.25).

Рисунок 25. Метамодель Архитектуры Унифицированного Метода UMA

Архитектура UMA основана на следующих основных принципах разделения:

· Разделение базового наполнения методов и применения этого наполнения в процессах

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

· Упаковка и настройка наполнения методов, процессов и модулей в библиотеках методов

· Разделение полей рекомендуемых методов и описания указаний

· Разделение семантических элементов и их записи в диаграммах процессов

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

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

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

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

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

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

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

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

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

· Структура - операция представлена в виде последовательности составляющих ее задач.

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

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

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

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

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

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

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

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

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

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

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

Рисунок 26. Наполнение метода и его применение в процессе

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

Рисунок 27. Обзор позиционирования основных концепций UMA в зависимости от того, что они представляют: наполнение методов или процессы

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

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

· Роль (Role)

· Задача (Task)

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

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

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

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

· Артефакт

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

· Исход

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· Операция

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При моделировании процесса внедрения ERP решений компании SAP AG на базе архитектуры унифицированного метода (UMA) был использован Унифицированный Язык Моделирования (Unified Modeling Language, UML). При этом использовалась нотация диаграмм деятельности (activity diagram) подмножества языка UML 2.0, расширенного в соответствии с архитектурой UMA, - Метамодели Процесса Инжиниринга Программного Обеспечения SPEM 2.0 (Software Process Engineering Metamodel), как изображено на рисунке 25.

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

Рисунок 28. Пример диаграммы деятельности в UML 2.0

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

Расширенная версия диаграмм деятельности наделяет абстрактные блоки деятельности, изображенные на рисунке 28 прямоугольниками, дополнительной семантикой:

· Этап (фаза)

· Операция

· и др.

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

· дескриптор Задачи

· дескриптор Роли

· дескриптор Рабочего продукта

Пример специфической декомпозиции операции на элементарные задачи приведен на рисунке 29:

Рисунок 29. Пример диаграммы деятельности специфической декомпозиции операции на элементарные задачи

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

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

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

3.2 Инструментальное средство моделирования

Для реализации практической части данной аттестационной работы было использовано CASE-средство моделирования процессов разработки и внедрения программного обеспечения Rational Method Composer 7.2.0. Данный инструмент широкодоступен как для компаний, так и для физических лиц после регистрации на сайте производителя http://www.ibm.com/ в полнофункциональной Trial версии длительностью использования 30 дней на различных языках, в том числе и на русском.

В основе инструментального средства моделирования Rational Method Composer 7.2.0 лежит та же Архитектура Унифицированного Метода UMA (Unified Method Architecture) и та же нотация моделирования SPEM 2.0 (расширение UML 2.0), которые находят свое отражение в интерфейсе этого программного продукта (рис.30):

Рисунок 30. Интерфейс программного продукта Rational Method Composer 7.2.0

Интерфейс программного продукта Rational Method Composer 7.2.0 разделен вертикально на две основные области.

Слева - область визуального отображения:

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

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

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

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

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

Рисунок 31. Рабочая область пользовательского плагина (модуля метода) ASAP

Рисунок 32. Рабочая область пользовательской конфигурации

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

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

3.3 Формализованное описание процесса внедрения ERP систем SAP на отечественных предприятиях

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

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

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

Необходимо также отметить концептуальное подобие обеих концепций, которое отчетливо видно при сопоставлении рисунков 16 и 26:

· С точки зрения Наполнения Методов:

o Области знаний (knowledge areas) дорожной карты ASAP были реализованы в концепции Дисциплин метамодели UMA. Единственное принципиальное отличие заключается в том, что в методологии ASAP задачи могут включаться лишь в одну область знаний, а метамодель UMA позволяет включать задачи в различные категории, в том числе и Дисциплины;

o Работы (deliverables) дорожной карты ASAP были реализованы в метамодели UMA как задачи;

o Роли (Roles) дорожной карты ASAP были перенесены в метамодель UMA без изменений с дополнительной группировкой в Наборы Ролей;

o Входные и Выходные Акселераторы (accelerators) дорожной карты ASAP были реализованы в метамодели UMA как рабочие продукты: артефакты, конечные продукты или исходы в зависимости от их характера. При наличии в дорожной карте ASAP прикрепленного файла с примером акселератора, соответствующему в UMA артефакту назначалось Указание вида Пример, к которому прикреплялся данный файл. Всем рабочим продуктам, в зависимости от их характера, были присвоены соответствующие домен и/или вид продукта работы;

· С точки зрения Процесса:

o Фазы дорожной карты ASAP были реализованы в метамодели UMA как Этапы, то есть особые операции верхнего уровня;

o Группы Работ (deliverable groups) дорожной карты ASAP были реализованы в метамодели UMA как операции второго уровня и ниже;

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

o Роли (Roles) дорожной карты ASAP были реализованы в метамодели UMA как дескрипторы ролей нижнего уровня декомпозиции операций;

o Входные и Выходные Акселераторы (accelerators) дорожной карты ASAP были реализованы в метамодели UMA как дескрипторы рабочих продуктов нижнего уровня декомпозиции операций;

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

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

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

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

· Процесс внедрения (ASAP);

· Наборы Ролей;

· Дисциплины (области знаний);

· Документация

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

Рисунок 33. Вкладка 'Процесс внедрения (ASAP)' прототипа. В рабочей области справа - содержимое вкладки 'Описание'

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

На этой вкладке приводится общая информация о той или иной операции процесса, выбранной в меню слева.

Остальные три вкладки рабочей области представления процесса предназначены для его детального описания с трех точек зрения (рис.34 - 36):

· Структурной декомпозиции работ (диаграмма деятельности и дерево структуры декомпозиции)

· Распределения работ между членами команды проекта

· Рабочих Продуктов операции

Рисунок 34. Вкладка 'Процесс внедрения (ASAP)' прототипа. В рабочей области справа - содержимое вкладки 'Структура работы'

Рисунок 35. Вкладка 'Процесс внедрения (ASAP)' прототипа. В рабочей области справа - содержимое вкладки 'Распределение групп'

Рисунок 36. Вкладка 'Процесс внедрения (ASAP)' прототипа. В рабочей области справа - содержимое вкладки 'Использование рабочего продукта'

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

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

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

Вкладка 'Дисциплины (области знаний)' (рис.38) помогает представить элементы процесса в разрезе Дисциплин, то есть с точки зрения группировки по категориям наполнения методов. Это представление полезно, если необходимо выделить определенные группы работ, объединенные в одну 'область знаний ASAP', например 'Менеджмент Данных Жизненного Цикла'.

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

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

· Документация Продукта - документация, предназначенная для поставки в составе продукта проекта внедрения, предназначенная для использования, как членами команды проекта, так и заказчиком после завершения проекта внедрения

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

Рисунок 37. Вкладка 'Наборы Ролей' прототипа. В рабочей области справа - содержимое соответствующего пункта древовидного меню

Рисунок 38. Вкладка 'Дисциплины (области знаний)' прототипа. В рабочей области справа - содержимое соответствующего пункта древовидного меню

Рисунок 39. Вкладка 'Документация' прототипа. В рабочей области справа - содержимое соответствующего пункта древовидного меню

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

· Модели фрагмента методологии ASAP (позволяет создавать экземпляры методологии со смещением, как по оси итеративности, так и по оси методологического веса 'карты процессов')

· Опубликованного прототипа инструментария управления проектом внедрения ERP решений SAP на отечественных предприятиях, исключающего методологические недостатки ASAP.

Вывод

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

При этом были успешно решены выявленные проблемы внедрения данных решений, связанные с:

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

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

o в сторону вариантности формализованности (как высокой, так и низкой);

· Усилением методологии инструментарием, в котором как минимум:

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

Заключение

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

ь Раскрыта сущность программного обеспечения:

ь Рассмотрено понятие методологии процесса создания и внедрения программного обеспечения;

ь Классифицированы и сопоставлены основные методологии;

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

ь Изучена методология AcceleratedSAP, сопоставлена с другими методологиями:

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

ь Изучены сильные и слабые стороны ASAP;

ь Выявлены три существенных методологических недостатка ASAP, вызывающие методологические проблемы при использовании для внедрения ERP систем компании SAP AG на отечественных предприятиях;

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

· Установлена принципиальная возможность реализации концептуального пересмотра методологии ASAP на методологической платформе RUP:

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

o в сторону вариантности формализованности (как высокой, так и низкой);

· Усиление методологии инструментарием, в котором как минимум:

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

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

Они являются формальным описанием основных требований, которые могут лечь в основу фундаментальных методологических разработок, направленных на практическое создание новой методологии внедрения ERP систем компании SAP AG на отечественных предприятиях, разработанной на основе AcceleratedSAP в среде методологической платформы RUP.

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

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

1. Фредерик Брукс. Мистический человеко-месяц или как создаются программные системы. С-П.: 'Символ Плюс', 2007, 298 стр.

2. Стефан Бергстрем. Rational Unified Process - путь к успеху. Руководство по внедрению RUP. М.: 'КУДИЦ-ОБРАЗ', 2004, 256 стр.

3. Пер Кролл, Филипп Крачтен. Rational Unified Process - это легко. Руководство по RUP для практиков. М.: 'КУДИЦ-ОБРАЗ', 2004, 427 стр.

4. Гарри Поллис, Лиз Огастин, Крис Лоу, Джас Мадхар. Разработка программных проектов на основе Rational Unified Process (RUP). М.: 'Бином', 2005, 255 стр.

5. Мартин Фаулер. UML основы. Краткое руководство по стандартному языку объектного моделирования. С-П.: 'Символ', 2005, 184 стр.

6. Роберт Фатрелл, Дональд Шафер, Линда Шафер. Управление программными проектами. Достижение оптимального качества при минимуме затрат. М.: ИД 'Вильямс', 2004, 1125 стр.

7. Лен Басс, Пол Клементс, Рик Кацман. Архитектура программного обеспечения на практике. М.: 'ПИТЕР', 2006, 574 стр.

8. Джеймс Рамбо, Айвар Якобсон, Грэди Буч. UML. М.: 'ПИТЕР', 2006, 735 стр.

Список дополнительного материала

9. ASAP V3.7 CPL, 2007.

10. RUP 7.2, 2007.