Oracle / PeopleSoft One Methodology

Тема 6. СОВРЕМЕННЫЕ МЕТОДОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Корпоративные методологии

Индустриальные стандарты и методологии

Корпоративные методологии

IBM (Rational Unified Process, RUP) Один из наиболее ориентированных на пользователя подходов, RUP (Rational Unified Process) предполагает итеративную разработку, большое внимание к архитектуре, к потенциальным рискам, и главное – к управлению на основе пользовательских «юзкейсов» (use-cases).

«Юзкейсы определяют соглашение между стейкхолдерами системы относительно ее поведения. Юзкейс описывает поведение системы при различных условиях в ответ на запрос со стороны одного из стейкхолдеров» (Коберн).

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

Важно, что RUP, представляя собой в конечном счете набор решений оптимизации разработки ПО. В частности, компания Rational Software (в 2003-м году ставшая подразделением IBM), описав возможные роли участников проектов, все возможные виды проектных документов для каждого из них, как и формы распределения ответственности, создала программное решение для поддержки всего процесса разработки. И его использование по сути гарантирует достижение третьей стадии зрелости модели CMM, что для многих процессов многих организаций является достаточным уровнем развития. Данный инструмент, IBM Rational Method Composer, позволяет создавать, конфигурировать и публиковать определенные процессы разработки.

И наконец, RUP содержит шесть основных «лучших практик», описанных в RUP и направленных на повышение продуктивности и снижение вероятности появления ошибок (снижение рисков):

‒ Итеративная разработка.

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

‒ Управление требованиями.

‒ Компонентный подход.

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

‒ Визуальное моделирование.

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

‒ Поддержание уровня качества.

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

‒ Мониторинг изменений.

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

Microsoft (Microsoft Solution Framework, MSF)

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

Однако в контексте рассмотрения ЖЦ ПО нас интересует именно методология разработки: как являющийся одним из основных аспект управления и взаимодействия участников процесса, так и другие области знаний (управление рисками, планирование). В целом охватываемые MSF дисциплины описаны в пяти частях (т.н. «белых книгах»), однако интересно, что командами консультантов Microsoft применяется на практике не этот ресурс, а методика MSF for Agile Software Development, являясь прикладным вариантом MSF и разумеется, отражая общий методологический подход к итеративной разработке. Если обратиться непосредственно к процессу разработки / внедрения, то его характеризуют:

‒ Итеративность.

‒ Формирование в качестве результата ИТ-решения.

Таким образом, в отличие от многих других корпоративных методологий, определенные в MSF этапы / вехи, состав проектной группы, ролевая модель и другие элементы подходят не только для решений Microsoft. А значит, MSF представляет собой более гибкий и универсальный подход для внедрения других систем / программных продуктов. On Target Методология внедрения решений On Target была разработана компанией Navision для внедрения своих программных продуктов. После приобретения Navision и вхождения ее в состав Microsoft было принято решение доработать On Target, к тому моменту содержавшую шаблоны описаний бизнес-процессов, документации, организационных структур ИТ и квалификационных требований к специалистам. Рассмотрим основные этапы внедрения в соответствии с On Target: ‒ Подготовка проекта. -Формирование проектной команды и подготовка документации. ‒ Анализ. -Формирование функциональных требований к системе по результатам анализа бизнес-процессов. -Обучение ключевых пользователей, разработчиков и системных администраторов со стороны компании заказчика. ‒ Дизайн. Разработка и согласование технического задания и эскизного проекта. Финализация плана проекта и бюджета. ‒ Разработка и тестирование. Написание программного кода, разработка интерфейсов, настройка и тестирование. ‒ Развертывание. Установка системы на стендовом сервере и рабочих местах заказчика, настройка прав доступа, миграция данных, подготовка системной документации и инструкций пользователей, их обучение. ‒ Опытная эксплуатация. Приемка в ОПЭ, окончательная верификация данных и процедур после миграции, опытная эксплуатация, передача в промышленную эксплуатацию. В силу того, что к моменту приобретения Navision у Microsoft уже применялись свои проверенные корпоративные методологии MSF и MOF, в дальнейшем On Target была дополнена и к моменту выведения на рынок Microsoft Dynamics превратилась в результате доработок в MS Dynamics Sure Step / Microsoft Business Solutions Partner Methodology. Microsoft Dynamics Sure Step и Microsoft Business Solutions Partner Methodology Sure Step была разработана для партнерской сети Misrosoft с целью обеспечения единого подхода к внедрению решений класса MS Dynamics (почему и получила название MS Business Solutions Partner Methodology, в частности используемое для программного решения Modeling Tool). Она основывается на лучших практиках проектов внедрения и для соответствия различным сценариям предлагает несколько компонентов: С предшествующей методологии On Target отличия незначительные: Подготовка проекта заменена на Диагностику, а Опытная эксплуатация на Начальное сопровождение. Соответственно, охватывается уже не только внедрение, но и поддержка заказчика по различным каналам коммуникации, периодические обновления, а также планирование новых проектов. ‒ Процессы. ПРИМЕР На стадии дизайна схема процессов выглядит следующим образом:

Предложения.

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

ПРИМЕР Диагностика, подробный анализ; внедрение (полное либо быстрое); оптимизация.

‒ Отчетные материалы.

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

‒ оценка инфраструктуры;

‒ план проекта;

‒ функциональные требования;

‒ план и контрольный список реализации.

Отчетные материалы являются прямыми результатами соответствующих процессов этапов.

‒ Межэтапные (постоянные) процессы.

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

‒ анализ бизнес-процесса;

‒ конфигурация;

‒ перенос данных;

‒ инфраструктура;

‒ инсталляция;

‒ интеграция;

‒ тестирование;

‒ обучение.

Выделяются те операции, которые относятся к конкретным процессам и охватывают несколько этапов.

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

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

‒ Роли консультантов и клиентов.

Sure Step определяет основные роли специалистов со стороны заказчика внедрения и подрядчиков и охватывает рекомендации для каждой из них.

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

Таким образом, MS Dynamics Sure Step представляет собой комплексную методологию внедрения, оптимальную для программных продуктов Dynamics CRM, AX, NAV за счет подробных шаблонов и схем процессов, а также средств редактирования для адаптации методологии к специфике предприятия и отрасли. Методология определяет необходимые шаги каждого этапа внедрения продуктов MS Dynamics как в виде иерархической струк-туры работ, так и в виде графических схем процессов MS Visio.

SAP (Accelerated SAP)

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

В целом же корпоративная методология Accelerated SAP (ASAP) предлагает комплексный инструментарий, сочетающий технологическую и управленческую части в виде трех основных компонентов:

‒ Синхронизация бизнес-приоритетов клиента (в зависимости от индустрии) с конкретными решениями SAP через отраслевые карты бизнес-ценностей (value maps) инструмента Solution Explorer.

‒ Карты управления проектами (маршрутные карты) с основными этапами и активностями по ним.

‒ Проектирование, настройка, тестирование и эксплуатация решения при помощи менеджера решений SAP Solution Manager.

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

Oracle (Oracle Unified Method, OUM)

Oracle Unified Method (OUM) – корпоративная методология поддержки ЖЦ информационных технологий на предприятии, содержащая общее руководство по настройке и типовую структуру работ, а также набор шаблонов, комплекты материалов по конкретным продуктам Oracle и необходимые программные инструменты. Изначально основой методологии Oracle стала модель унифицированного процесса разработки (Unified Process), которая была адаптирована также IBM для формирования собственной корпоративной методологии Rational Unified Process. OUM охватывает три основных аспекта: управление программами и проектами, поддержку ИТ-архитектуры и подход к реализации проектов. Выделяя аналогичные ASAP пять стадий, Oracle изначально предполагает возможность итераций внутри каждой из них (две итерации проектирова-ния, три итерации разработки) с наглядным представлением, на каком именно из 15ти процессов разработки следует фокусироваться в каждый конкретный момент. Вполне резонно методология от Oracle предполагает регулярные активности процессов управления изменениями и документацией, множество раундов тестирования и контроля производительности, отдельное внимание технической архитектуре, обучение (в особенности на начальной стадии и в ходе разработки при подготовки к эксплуатации). А релизы поддерживают также сервис-ориентированную архитектуру, управление учетными записями, идеологию Entreprise 2.0 и другие актуальные проектные технологии, что способствует популярности данного метода разработки ПО среди кор-поративных клиентов.

Oracle / PeopleSoft One Methodology

Разработанная компанией PeopleSoft, вошедшей в состав Oracle данная методология предназначена для описания внедрения ИС американской компании JD Edwards (в свою очередь, тоже поглощенной PeopleSoft). Первоначально разрабатывая финансовое ПО под аппаратное обеспечение IBM, JD Edwards создала методологию, в равной степени применимую к разным категориям систем: управления ресурсами, цепочками поставок, взаимоотношениями с клиентами, интеллектуального анализа данных и сотрудничества в Интернет.

Среди некоторых целей One Methodology – создание единой системы из иерархии целей проекта, его ограничений и планируемых результатов, фор-мирование требований к команде внедрения, определение политики в области рисков. Содержание этапов данной методологии значительно отличается от рассмотренных ранееОднако в результате последовательного поглощения JD Edwards - PeopleSoft - Oracle и значительной направленности JD Edwards на узкую линию программных продуктов, данная методология потеряла свою актуальность и уступила место другим методологиям, в частности, разработанной Oracle AIM в составе Oracle Unified Method.

2. Индустриальные стандарты и методологии

Agile

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

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

2. Приоритет получения работающего продукта над исчерпывающей всеобъемлющей документацией.

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

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

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

В качестве одного из важнейших элементов Agile-подхода к разработке выступают пользовательские истории (user stories). Это описанные одним или несколькими предложениями основные аспекты функциональности системы, необходимые для выполнения пользователем своей работы. В достаточно сжатом виде, они должны отвечать на вопросы: «Кто?», «Что?» и «Почему?» и могут создаваться как менеджером проекта по результатам обследования как один из форматов фиксирования требований, так и разработчиками для выражения нефункциональных требований (например, к безопасности, производительности, качеству решения). В то же время, agile почти не ограничивает команду проекта: так, если необходим больший уровень детализации технического задания / спецификаций / другой документации – можно его написать, если необходимы дополнительные приемочные критерии – можно их составить, если нужны прототипы – можно их сформировать или в виде макетов (мокапов, mockups), или в виде блок-схем, или в виде реальной модели прототипа. Уровень детализации и формализации всегда зависит от специфики системы и проектной команды, от их компетенций и опыта реализации подобных проектов.

SCRUM

В переводе с английского языка «SCRUM» означает «схватка». Впервые подобная методология была введена в употребление профессорами японского Hitotsubashi University в их статье «Новая игра в производстве продукта» («The New Product Development Game»), написанной в 1986 году. В ней разработка продукта была сравнена со схваткой вокруг мяча в регби – приемом, называемым «скрам». Тем не менее, авторами концепции считаются разработчики из США, Кен Швабер и Джефф Сазерленд, впервые определившие и описавшие основополагающие принципы SCRUM – «гибкой» методологии управления проектами (чаще всего применяющейся в области разработки ПО). По своей сути SCRUM представляет собой набор принципов разработки, которые позволяет представлять конечному пользователю (и заказчику) действующий продукт / прототип, обладающий новыми функциями и возможностями с наивысшим приоритетом. Работа в этом случае проводится в четко фиксированные недлительные (в среднем от 1 до 6 недель, чаще от 2 до 4) итерации (спринты). Ожидаемые результаты спринта определяются командой под руководством SCRUM-мастера в самом его начале и не могут изменяться до завершения. К ним под руководством SCRUM-мастера (по сути руководителя проекта) и product-мастера (заказчика, владельца проекта) создается список работ на период спринта и на весь проект (sprint-back-log и product-backlog соответственно). С одной стороны, в силу того, что релизы выпускаются часто, минимизируется вероятность ошибок за счет постоянной обратной связи с потребителями при демонстрации новой функциональности, а также ежедневных (!) встреч команды проекта. С другой стороны, увеличиваются временные (и денежные) затраты на проведение презентаций, а также на исправление выявленных проблем и осуществляемый ретроспективный анализ. Однако при более глубоком рассмотрении SCRUM имеет очень важные основы: методология предполагает циклический и очень активный процесс, минимизирующий неопределенность требований за счет коротких итераций и предоставляя возможность детального прототипирования. Долгие, нестандартные, динамические проекты, при расплывчатом представлении о конечном ожидаемом результате и постоянной смене приоритетов не являются проблемой для SCRUM, и именно поэтому он часто применяется на первых этапах, затем в целях экономии средств / ресурсов переходя к использованию другой методологии. Соответственно, SCRUM может применяться практически любым типом организаций – от стартапов с их высокой неопределенностью до госзаказчиков с частым изменением требований и частой необходимостью демонстрации текущей версии для отчета о результатах.

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

RAD

Методология быстрой разработки приложений RAD (rapid application development) предполагает наличие трех основных элементов: небольшой команды до 10 человек, непродолжительный период внедрения в 2-6 месяцев и итеративный цикл, в основе которого спиральная модель жизненного цикла ИС. Основу разработки RAD составляет использование инструментальных средств для каждой фазы жизненного цикла системы – анализа требований, проектирования, генерации кода и разработки интерфейса. Часто используются CASE-средства и инструменты прототипирования интерфейса, которые позволяют продемонстрировать саму концепцию планируемого результата уже в самом начале проекта. Именно поэтому итерационный принцип настолько соответствует методологии и он удобен при нечетко определенных и изменяющихся требованиях к итоговой системе. Итоговый результат, работоспособная система, актуальная на текущий момент (не обязательно в перспективе нескольких лет!) может быть получен более оперативно именно при помощи RAD. Однако есть и некоторые отличия с традиционной спиральной моделью. В силу этого же итеративного подход, как и другие подобные методологии, RAD не может применяться для разработки сложных систем. (например, от которых зависит безопасность людей, таких как системы управления судами или самолетами), так как первые версии не будут полностью работоспособны. Не следует удивляться также и предложению подрядчика использовать принципы RAD на первых этапах, затем переписывая часть кода на «традиционном» языке программирования – таком, как C# или C++. Преимуществом RAD среди методологий разработки является совместная работа с заказчиком / бизнес-пользователями, которые активно участвуют в прототипировании, написании сценариев тестирования и его проведении. Другой особенностью является совместное принятие решений команды, и подобный децентрализованный стиль управления может привести к периодической смене курса проекта или возможному излишне длительному принятию решения из-за поиска консенсуса.

Основная особенность методологии экстремального программирования (eXtreme Programming) состоит в ее эффективности в условиях неопределенных или нечетких требований. Популярность данного подхода увеличивалась по мере роста числа разработчиков, недовольных традиционным подходом со множеством формальных требований и постоянно готовивших документацию, собиравшими информацию о показателях проекта. Напротив, новая методология предлагала простой дизайн, переработку (ре-факторинг) кода для контроля затрат, постоянное присутствие заказчика, разработку через тесты и другие аспекты, выгодно отличавшие ее. Обозначим другие ключевые аспекты данной методологии. Для работы в подобных условиях необходима постоянная связь с заказчиком, которая обеспечивается полноценным участием в работе проектной команды квалифицированного, находящегося в курсе проекта представителя заказчика. При разработке в большинстве случаев выбираются наиболее простые методы, исходя из принципа того, что легче в будущем вносить дополнения в базовую версию, чем перестраивать усложненную (хотя, разумеется, бывают исключения, когда изначально учет многих факторов в системе может помочь избежать в дальнейшем многих сложностей). Принцип простоты также важен и в интерфейсном решении, когда более интуитивный пользовательский дизайн интерфейса обладает исключительно необходимыми (но не излишними!) функциями. Однако предварительное детальное проектирование интерфейса согласно исходной версии методологии не осуществляется, он создается лишь по мере работы команды в течение проекта. Коллективная работа по написанию кода / внесению изменений в настройки. Этот принцип относится к двум аспектам. В первую очередь, это «коллективное владение кодом», когда любой участник команды разработчиков может внести изменения благодаря единым правилам оформления когда и использованию стандартов для ПО. С другой стороны, применяется метод «парного программирования», в соответствии с которым двое разработчиков используют один компьютер, чередуя написание кода и доработку настроек, реализацию требований и прочие вопросы.

Дата добавления: 2021-04-24; просмотров: 180; Мы поможем в написании вашей работы!

Поделиться с друзьями:

Мы поможем в написании ваших работ!