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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· и т.д.

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

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

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

Рисунок 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):

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

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

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

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

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

Рисунок 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):

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

Рисунок 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):

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

Рисунок 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 систем на отечественных предприятиях;

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

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

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