В течение каких этапов проекта выполняются работы процесса ввод в эксплуатацию по методологии oracle aim
AIM – Application Implementation Method – методика внедрения готовых приложений, разработана компанией Оракл для внедрения пакета готовых приложений Oracle E-Business Suite. Методика AIM практически не использует специфических особенностей Oracle E-Business Suite, поэтому она с одинаковым успехом может быть применена при внедрении любой ERP-системы и, вообще говоря, любого готового приложения, ориентированного на «автоматизацию» бизнес-процессов. Основную суть методики составляет адаптация бизнес-процессов к применению информационных технологий и, одновременно, адаптации этих самых информационных технологий к конкретным бизнес-процессам.
На настоящий момент не существует отечественных методик и/или стандартов (ГОСТов) в области внедрения готовых приложений. Учитывая современную мировую интеграцию в области стандартизации, а также ненаверстываемое в ближайшем будущем отставание отечественной индустрии сложных программных разработок, теперь уже нет никакого смысла в разработке отечественных методик.
При внедрении готовых приложений в бизнес-областях, обусловленных специфическим регламентом, или наоборот, четко не регламентированных, применение AIM не имеет смысла. В самом деле:
· в узкоспециализированной деятельности бизнес-процессы обычно не поддаются изменению, а потому само приложение должно быть написано точно под бизнес (и не нужно методики, чтобы его внедрять),
· в нерегламентированном бизнесе, по определению, бизнес-процессы четко не определены, поэтому подгонять приложение не подо что.
Как пример узкоспециализированной области можно привести налоговый учет, не регламентированной - стратегическое планирование.
Когда по тексту будет важно понимать, идет ли речь о «стандартном» AIM или модифицированной методике, для модифицированной будет применяться термин AIM-M.
Существует детальная фирменная документация на Oracle AIM версии 3 и версии 2.5 (на английском языке). В данном тексте используется структура задач по версии 2.5, поскольку эта версия кажется менее перегруженной не основными задачами, а в целом методика обоих версий одинакова.
Основные понятия AIM
При внедрении готовых приложений пакета Oracle E-Business Suite используется ноу-хау методика, выработанная и апробированная компанией Oracle в ходе внедрения пакета собственным подразделением консалтинга. Данная методика - AIM(Applications Implementation Method, Метод внедрения приложений) - представляет собой детальное описание задач, выполняемых в ходе проекта, с указанием последовательности выполнения и ответственных ролей проектной группы.
Задача в терминах методики AIM представляет собой элементарный (неделимый) объем работ, который обязательно заканчивается формально фиксируемым результатом.
Все задачи сгруппированы в процессы по принципу общности результата. Выделяются следующие процессы внедрения:
· Определение бизнес-требований- результатом выполнения задач, входящих в данный процесс, является описание требований заказчика к развертываемой системе. В ходе этого процесса выявляются детальные алгоритмы, по которым происходит выполнение хозяйственной деятельности (бизнес-процессов) заказчика в области, затрагиваемой развертыванием автоматизированной системы. Затем разрабатываются детальные модели хозяйственной деятельности (бизнес-процессов) заказчика после развертывания системы, которые затем детализируются до уровня конкретных функций, выполняемых системой для каждого элементарного шага бизнес-процесса.
· Отображение бизнес-требований- в ходе выполнения задач, входящих в данный процесс, проводится анализ того, какая функциональность Oracle E-Business Suite и каким образом может использоваться для реализации функциональных возможностей, необходимых заказчику. В этом процессе окончательно определяется, каким образом будут осуществляться хозяйственные процессы (бизнес-процессы) заказчика после развертывания системы, какая информация будет храниться в системе и какие доработки необходимо сделать, а также значения параметров настройки Oracle E-Business Suite.
· Функциональная и техническая архитектура – в ходе этого процесса происходит построение технической архитектуры, необходимой для работы системы, а также определяются значения ключевых параметров настройки Oracle E-Business Suite, касающихся архитектуры.
· Разработка дополнительной функциональности – в рамках этого процесса разрабатывается программное обеспечение, необходимое для реализации функциональности, отсутствующей в Oracle E-Business Suit.
· Конвертация данных – процесс охватывает задачи, связанные с переносом данных из существующих систем (возможно в бумажном виде) во внедряемую систему. Выявляются объекты, содержащие необходимые данные, определяются методы загрузки этих данных в систему. Разрабатываются и выполняются программы переноса.
· Документирование – в этом процессе создается документация на систему.
· Тестирование системы - на основе требований к функциональности системы, собранных и детализированных в ходе процессов определения и отображения бизнес-требований, разрабатываются сценарии тестирования и производится проверка системы на реализуемость требований.
· Тестирование на производительность- в ходе этого процесса выполняются задачи, связанные с тестированием системы на «узкие» места по производительности.
· Обучение - этотпроцесс разбивается на две части - обучение проектной группы, с которого начинается проект по внедрению, и обучение конечных пользователей, которым проект заканчивается.
· Ввод в эксплуатацию- в ходе этого процесса рассматриваются все вопросы, связанные с вводом в эксплуатацию системы и ее последующим сопровождением.
Все работы по проекту разбиваются на временные фазы. Выделяются следующие фазы:
· Определение – по окончании данной фазы определяются совокупные бизнес-требования заказчика. Впоследствии они могут уточняться и видоизменяться в ходе отображения на функциональность Oracle E-Business Suite, но появления новых бизнес-требований не происходит.
· Анализ операций – по окончании данной фазы будущие бизнес-процессы зафиксированы и определено, как они будут реализованы с помощью Oracle E-Business Suite. Так же точно определено, какие бизнес-требования не могут быть удовлетворены с помощью стандартной функциональности и какая дополнительная разработка необходима.
· Проектирование решения - в ходе данной фазы в частности производится создание детальных спецификаций для дополнительной разработки (функциональный и технический дизайн) и разработка сценариев тестирования.
· Разработка – по окончании данной фазы все дополнительные разработки завершены, приемочные тесты проведены, пользовательская документация разработана.
· Переход к эксплуатации - в ходе этой фазы завершается обучение конечных пользователей, производится конвертация данных и система вводится в эксплуатацию.
· Эксплуатация системы – это начало фазы поддержки системы. В это время выявляются и исправляются все недочеты по работе системы.
Изучение и моделирование бизнеса
Сама суть проекта внедрения готового приложения заключается в адаптации бизнес-процессов в автоматизируемой области к применению информационных технологий. В ходе проекта осуществляется разработка модели будущих бизнес-процессов (процессов в условиях автоматизации) в целях адаптации приложения к бизнес-процессам и бизнес-процессов к приложению.
AIM подразумевает, что при создании начальной модели бизнеса применяется метод Oracle OBM. OBM – это модификация метода data-flow диаграмм.Вместо data-flow в OBM используется понятие information-flow, где под потоком между шагами обработки понимается не только данные, но и любая структурированная и неструктурированная информация, в том числе управляющие события. Интересующиеся могут посмотреть фирменную документацию по OBM; методика становится ясной с первого прочтения.
Использование графического изображения бизнеса очень наглядно, но трудоемко для выполнения проекта, учитывая, что картинки многократно по ходу проекта меняются. Кроме того, поскольку обойтись без текстовых описаний бизнеса невозможно, необходимо параллельно вести графическое и текстовое описание.
Для AIM-M был выработан свой подход к моделированию бизнеса, позволяющий в одном формате не только моделировать бизнес, но и выполнять основные задачи внедрения. При этом графические модели бизнеса применяются как вспомогательные. Основным инструментом моделирования в AIM-M является описание бизнеса в виде процедур формата Oracle Tutor.
Методика компании Oracle внедрения готовых приложений пакета Oracle E-Business Suite , называемая Application Implementation Method (AIM), является составной частью методического комплекса Oracle Method , который охватывает различные аспекты развития ИТ-инфраструктуры компании. Методология Oracle AIM представляет собой детальное описание задач, выполняемых в ходе проекта, с указанием последовательности их выполнения и ответственных ролей проектной группы [ 7 ] .
Общая схема исполнения проекта согласно AIM описывается следующей последовательностью действий:
- Строится грубая модель явления.
- Выявляются детальные требования к разным аспектам явления.
- Модель и детальные требования отображаются в приложении (приложение настраивается и демонстрируется).
- Если какие-то аспекты модели или требований не реализуются приложением, то формируется подход к их реализации.
- Стоимость реализации новых возможностей приложения оценивается, и если она "слишком" велика, то происходит возврат к перестройке модели или изменение требований.
- Если стоимость реализации новых возможностей оправдана, то новые компоненты приложения разрабатываются (и интегрируются в приложение).
- Составляются инструкции по использованию приложения, объединяющие стандартные и новые возможности приложения и базирующиеся на модели явления и на детальных требованиях к нему.
- Новая модель внедряется в жизнь.
Работы, выполняемые для решения этих задач, по принципу общности результатов сгруппированы в процессы. Проект делится на шесть фаз (см. рис. 2.1).
Основные цели, которые должны быть достигнуты в соответствующих фазах проекта
- В фазе Определение сформулированы совокупные бизнес-требования Заказчика. Впоследствии они могут уточняться и видоизменяться в ходе отображения на функциональность Oracle E-Business Suite, но появления новых бизнес-требований не происходит.
- В фазе Анализ операций зафиксированы будущие бизнес-процессы и определено, как они будут реализованы с помощью Oracle E-Business Suite; установлено, какие бизнес-требования не могут быть удовлетворены с помощью стандартной функциональности и какая дополнительная разработка необходима.
- В фазе Дизайн решения получены детальные спецификации для дополнительной разработки (функциональный и технический дизайн) и разработаны сценарии тестирования.
- В фазе Разработка завершены все дополнительные разработки, проведены приемочные тесты, разработана пользовательская документация для эксплуатации решения.
- В фазе Переход завершено обучение конечных пользователей, проведена конвертация данных, система введена в эксплуатацию.
- В фазе Эксплуатация - обеспечение поддержки Заказчика в работе с системой; устранение выявленных недостатков в работе системы.
Каждый из выделенных процессов подразумевает выполнение определенного комплекса работ .
- Определение бизнес-требований (RD). Результатом выполнения задач, входящих в данный процесс, является описание требований Заказчика к развертываемой системе. В ходе этого процесса создаются детальные описания выполнения бизнес-процессов Заказчика в заданной области автоматизации (модели "как есть"). Затем разрабатываются модели бизнес-процессов Заказчика, которые будут реализованы после развертывания системы (модели "как должно быть"). Последние затем детализируются до уровня конкретных функций, выполняемых системой для каждого элементарного шага бизнес-процесса.
- Отображение бизнес-требований (BR). В ходе выполнения задач этого процесса выясняется, какая функциональность Oracle E-Business Suite и каким образом может применяться для реализации необходимых Заказчику функциональных возможностей информационной системы. Окончательно определяются бизнес-процессы "как должно быть" и состав используемой в системе информации. Фиксируются значения параметров настройки программных модулей Oracle E-Business Suite и перечень необходимых доработок.
- Разработка архитектуры (TA). В ходе этого процесса происходит построение технической архитектуры, необходимой для работы системы, а также определяются значения ключевых параметров настройки Oracle E-Business Suite, касающихся архитектуры.
- Разработка дополнительной функциональности (MD). В рамках этого процесса разрабатывается программное обеспечение, которое необходимо для реализации функциональности, отсутствующей в Oracle E-Business Suit.
- Конвертация данных (CV). Процесс охватывает задачи, связанные с переносом данных из унаследованных систем в новую. Выявляются объекты, содержащие необходимые данные, определяются методы преобразования и загрузки этих данных в систему. Разрабатывается вспомогательное программное обеспечение.
- Документирование (DO). В этом процессе создается документация на систему.
- Тестирование функциональности (TE). На основе бизнес-требований разрабатываются сценарии тестирования и проводится проверка реализации этих требований в системе.
- Тестирование производительности (PT). Проверяется работоспособность системы в условиях реальной нагрузки (по количеству пользователей, документов, транзакций и пр.).
- Обучение (TR). Процесс включает в себя две основные задачи: обучение проектной группы (с него начинается проект по внедрению) и обучение конечных пользователей (им проект заканчивается).
- Ввод в эксплуатацию (PM). В ходе этого процесса рассматриваются все вопросы, связанные с организацией промышленной эксплуатации системы и ее сопровождением.
Процессы в AIM формируются из задач. Задача - элементарный (неделимый) объем работ , который обязательно заканчивается формально фиксируемым (документируемым) результатом. Если результат естественным образом в ходе выполнения задачи сформирован в электронной форме (например, выполнены настройки программного модуля), то он должен быть оформлен соответствующим документом, согласован и утвержден (обычно в бумажной форме). Если результатом задачи является выполненная работа, то он документируется в виде акта. Выполнение задачи дает результат либо полезный для целей проекта сам по себе, либо используемый для выполнения (в качестве входа) другой задачи. Задачи в AIM обозначаются двумя буквами (обозначение процесса) и двумя-тремя цифрами через точку.
В методологии приводится описание типовых ролей, которые исполняются участниками проекта при выполнении задач.
Описание выполняемых работ заключается в формировании цепочек задач, которые необходимо выполнить для достижения целей проекта.
Внедрение готового приложения заключается в одновременном согласовании возможностей приложения и организации исполнения автоматизируемых бизнес-процессов. Это приводит к необходимости настройки (доработки) приложения и модификации бизнес-процессов. Рекомендуемая последовательность действий определяется следующей цепочкой задач:
RD.020 - RD.030 - RD.070 - BR.020 - BR.080 - MD.020 - MD.060 - DO.070 - TE.110 - PM.050 - CV.140 - PM.080, где
Методика компании Oracle внедрения готовых приложений пакета Oracle E-Business Suite , называемая Application Implementation Method (AIM), является составной частью методического комплекса Oracle Method , который охватывает различные аспекты развития ИТ-инфраструктуры компании. Методология Oracle AIM представляет собой детальное описание задач, выполняемых в ходе проекта, с указанием последовательности их выполнения и ответственных ролей проектной группы [ 7 ] .
Общая схема исполнения проекта согласно AIM описывается следующей последовательностью действий:
- Строится грубая модель явления.
- Выявляются детальные требования к разным аспектам явления.
- Модель и детальные требования отображаются в приложении (приложение настраивается и демонстрируется).
- Если какие-то аспекты модели или требований не реализуются приложением, то формируется подход к их реализации.
- Стоимость реализации новых возможностей приложения оценивается, и если она "слишком" велика, то происходит возврат к перестройке модели или изменение требований.
- Если стоимость реализации новых возможностей оправдана, то новые компоненты приложения разрабатываются (и интегрируются в приложение).
- Составляются инструкции по использованию приложения, объединяющие стандартные и новые возможности приложения и базирующиеся на модели явления и на детальных требованиях к нему.
- Новая модель внедряется в жизнь.
Работы, выполняемые для решения этих задач, по принципу общности результатов сгруппированы в процессы. Проект делится на шесть фаз (см. рис. 2.1).
Основные цели, которые должны быть достигнуты в соответствующих фазах проекта
- В фазе Определение сформулированы совокупные бизнес-требования Заказчика. Впоследствии они могут уточняться и видоизменяться в ходе отображения на функциональность Oracle E-Business Suite, но появления новых бизнес-требований не происходит.
- В фазе Анализ операций зафиксированы будущие бизнес-процессы и определено, как они будут реализованы с помощью Oracle E-Business Suite; установлено, какие бизнес-требования не могут быть удовлетворены с помощью стандартной функциональности и какая дополнительная разработка необходима.
- В фазе Дизайн решения получены детальные спецификации для дополнительной разработки (функциональный и технический дизайн) и разработаны сценарии тестирования.
- В фазе Разработка завершены все дополнительные разработки, проведены приемочные тесты, разработана пользовательская документация для эксплуатации решения.
- В фазе Переход завершено обучение конечных пользователей, проведена конвертация данных, система введена в эксплуатацию.
- В фазе Эксплуатация - обеспечение поддержки Заказчика в работе с системой; устранение выявленных недостатков в работе системы.
Каждый из выделенных процессов подразумевает выполнение определенного комплекса работ .
- Определение бизнес-требований (RD). Результатом выполнения задач, входящих в данный процесс, является описание требований Заказчика к развертываемой системе. В ходе этого процесса создаются детальные описания выполнения бизнес-процессов Заказчика в заданной области автоматизации (модели "как есть"). Затем разрабатываются модели бизнес-процессов Заказчика, которые будут реализованы после развертывания системы (модели "как должно быть"). Последние затем детализируются до уровня конкретных функций, выполняемых системой для каждого элементарного шага бизнес-процесса.
- Отображение бизнес-требований (BR). В ходе выполнения задач этого процесса выясняется, какая функциональность Oracle E-Business Suite и каким образом может применяться для реализации необходимых Заказчику функциональных возможностей информационной системы. Окончательно определяются бизнес-процессы "как должно быть" и состав используемой в системе информации. Фиксируются значения параметров настройки программных модулей Oracle E-Business Suite и перечень необходимых доработок.
- Разработка архитектуры (TA). В ходе этого процесса происходит построение технической архитектуры, необходимой для работы системы, а также определяются значения ключевых параметров настройки Oracle E-Business Suite, касающихся архитектуры.
- Разработка дополнительной функциональности (MD). В рамках этого процесса разрабатывается программное обеспечение, которое необходимо для реализации функциональности, отсутствующей в Oracle E-Business Suit.
- Конвертация данных (CV). Процесс охватывает задачи, связанные с переносом данных из унаследованных систем в новую. Выявляются объекты, содержащие необходимые данные, определяются методы преобразования и загрузки этих данных в систему. Разрабатывается вспомогательное программное обеспечение.
- Документирование (DO). В этом процессе создается документация на систему.
- Тестирование функциональности (TE). На основе бизнес-требований разрабатываются сценарии тестирования и проводится проверка реализации этих требований в системе.
- Тестирование производительности (PT). Проверяется работоспособность системы в условиях реальной нагрузки (по количеству пользователей, документов, транзакций и пр.).
- Обучение (TR). Процесс включает в себя две основные задачи: обучение проектной группы (с него начинается проект по внедрению) и обучение конечных пользователей (им проект заканчивается).
- Ввод в эксплуатацию (PM). В ходе этого процесса рассматриваются все вопросы, связанные с организацией промышленной эксплуатации системы и ее сопровождением.
Процессы в AIM формируются из задач. Задача - элементарный (неделимый) объем работ , который обязательно заканчивается формально фиксируемым (документируемым) результатом. Если результат естественным образом в ходе выполнения задачи сформирован в электронной форме (например, выполнены настройки программного модуля), то он должен быть оформлен соответствующим документом, согласован и утвержден (обычно в бумажной форме). Если результатом задачи является выполненная работа, то он документируется в виде акта. Выполнение задачи дает результат либо полезный для целей проекта сам по себе, либо используемый для выполнения (в качестве входа) другой задачи. Задачи в AIM обозначаются двумя буквами (обозначение процесса) и двумя-тремя цифрами через точку.
В методологии приводится описание типовых ролей, которые исполняются участниками проекта при выполнении задач.
Описание выполняемых работ заключается в формировании цепочек задач, которые необходимо выполнить для достижения целей проекта.
Внедрение готового приложения заключается в одновременном согласовании возможностей приложения и организации исполнения автоматизируемых бизнес-процессов. Это приводит к необходимости настройки (доработки) приложения и модификации бизнес-процессов. Рекомендуемая последовательность действий определяется следующей цепочкой задач:
RD.020 - RD.030 - RD.070 - BR.020 - BR.080 - MD.020 - MD.060 - DO.070 - TE.110 - PM.050 - CV.140 - PM.080, где
Методика компании Oracle внедрения готовых приложений пакета Oracle E-Business Suite , называемая Application Implementation Method (AIM), является составной частью методического комплекса Oracle Method , который охватывает различные аспекты развития ИТ-инфраструктуры компании. Методология Oracle AIM представляет собой детальное описание задач, выполняемых в ходе проекта, с указанием последовательности их выполнения и ответственных ролей проектной группы [ 7 ] .
Общая схема исполнения проекта согласно AIM описывается следующей последовательностью действий:
- Строится грубая модель явления.
- Выявляются детальные требования к разным аспектам явления.
- Модель и детальные требования отображаются в приложении (приложение настраивается и демонстрируется).
- Если какие-то аспекты модели или требований не реализуются приложением, то формируется подход к их реализации.
- Стоимость реализации новых возможностей приложения оценивается, и если она "слишком" велика, то происходит возврат к перестройке модели или изменение требований.
- Если стоимость реализации новых возможностей оправдана, то новые компоненты приложения разрабатываются (и интегрируются в приложение).
- Составляются инструкции по использованию приложения, объединяющие стандартные и новые возможности приложения и базирующиеся на модели явления и на детальных требованиях к нему.
- Новая модель внедряется в жизнь.
Работы, выполняемые для решения этих задач, по принципу общности результатов сгруппированы в процессы. Проект делится на шесть фаз (см. рис. 2.1).
Основные цели, которые должны быть достигнуты в соответствующих фазах проекта
- В фазе Определение сформулированы совокупные бизнес-требования Заказчика. Впоследствии они могут уточняться и видоизменяться в ходе отображения на функциональность Oracle E-Business Suite, но появления новых бизнес-требований не происходит.
- В фазе Анализ операций зафиксированы будущие бизнес-процессы и определено, как они будут реализованы с помощью Oracle E-Business Suite; установлено, какие бизнес-требования не могут быть удовлетворены с помощью стандартной функциональности и какая дополнительная разработка необходима.
- В фазе Дизайн решения получены детальные спецификации для дополнительной разработки (функциональный и технический дизайн) и разработаны сценарии тестирования.
- В фазе Разработка завершены все дополнительные разработки, проведены приемочные тесты, разработана пользовательская документация для эксплуатации решения.
- В фазе Переход завершено обучение конечных пользователей, проведена конвертация данных, система введена в эксплуатацию.
- В фазе Эксплуатация - обеспечение поддержки Заказчика в работе с системой; устранение выявленных недостатков в работе системы.
Каждый из выделенных процессов подразумевает выполнение определенного комплекса работ .
- Определение бизнес-требований (RD). Результатом выполнения задач, входящих в данный процесс, является описание требований Заказчика к развертываемой системе. В ходе этого процесса создаются детальные описания выполнения бизнес-процессов Заказчика в заданной области автоматизации (модели "как есть"). Затем разрабатываются модели бизнес-процессов Заказчика, которые будут реализованы после развертывания системы (модели "как должно быть"). Последние затем детализируются до уровня конкретных функций, выполняемых системой для каждого элементарного шага бизнес-процесса.
- Отображение бизнес-требований (BR). В ходе выполнения задач этого процесса выясняется, какая функциональность Oracle E-Business Suite и каким образом может применяться для реализации необходимых Заказчику функциональных возможностей информационной системы. Окончательно определяются бизнес-процессы "как должно быть" и состав используемой в системе информации. Фиксируются значения параметров настройки программных модулей Oracle E-Business Suite и перечень необходимых доработок.
- Разработка архитектуры (TA). В ходе этого процесса происходит построение технической архитектуры, необходимой для работы системы, а также определяются значения ключевых параметров настройки Oracle E-Business Suite, касающихся архитектуры.
- Разработка дополнительной функциональности (MD). В рамках этого процесса разрабатывается программное обеспечение, которое необходимо для реализации функциональности, отсутствующей в Oracle E-Business Suit.
- Конвертация данных (CV). Процесс охватывает задачи, связанные с переносом данных из унаследованных систем в новую. Выявляются объекты, содержащие необходимые данные, определяются методы преобразования и загрузки этих данных в систему. Разрабатывается вспомогательное программное обеспечение.
- Документирование (DO). В этом процессе создается документация на систему.
- Тестирование функциональности (TE). На основе бизнес-требований разрабатываются сценарии тестирования и проводится проверка реализации этих требований в системе.
- Тестирование производительности (PT). Проверяется работоспособность системы в условиях реальной нагрузки (по количеству пользователей, документов, транзакций и пр.).
- Обучение (TR). Процесс включает в себя две основные задачи: обучение проектной группы (с него начинается проект по внедрению) и обучение конечных пользователей (им проект заканчивается).
- Ввод в эксплуатацию (PM). В ходе этого процесса рассматриваются все вопросы, связанные с организацией промышленной эксплуатации системы и ее сопровождением.
Процессы в AIM формируются из задач. Задача - элементарный (неделимый) объем работ , который обязательно заканчивается формально фиксируемым (документируемым) результатом. Если результат естественным образом в ходе выполнения задачи сформирован в электронной форме (например, выполнены настройки программного модуля), то он должен быть оформлен соответствующим документом, согласован и утвержден (обычно в бумажной форме). Если результатом задачи является выполненная работа, то он документируется в виде акта. Выполнение задачи дает результат либо полезный для целей проекта сам по себе, либо используемый для выполнения (в качестве входа) другой задачи. Задачи в AIM обозначаются двумя буквами (обозначение процесса) и двумя-тремя цифрами через точку.
В методологии приводится описание типовых ролей, которые исполняются участниками проекта при выполнении задач.
Описание выполняемых работ заключается в формировании цепочек задач, которые необходимо выполнить для достижения целей проекта.
Внедрение готового приложения заключается в одновременном согласовании возможностей приложения и организации исполнения автоматизируемых бизнес-процессов. Это приводит к необходимости настройки (доработки) приложения и модификации бизнес-процессов. Рекомендуемая последовательность действий определяется следующей цепочкой задач:
RD.020 - RD.030 - RD.070 - BR.020 - BR.080 - MD.020 - MD.060 - DO.070 - TE.110 - PM.050 - CV.140 - PM.080, где
Разработка программного продукта знает много достойных методологий — иначе говоря, устоявшихся best practices. Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны методологии, с которыми мы регулярно сталкиваемся в Эдисоне.
5. «Agile Model» (гибкая методология разработки)
В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.
В основе такого типа — непродолжительные ежедневные встречи — «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:
- отчёт о проделанной работе с момента последнего Scrum’a;
- список задач, которые сотрудник должен выполнить до следующего собрания;
- затруднения, возникшие в ходе работы.
Когда использовать Agile?
- Когда потребности пользователей постоянно меняются в динамическом бизнесе.
- Изменения на Agile реализуются за меньшую цену из-за частых инкрементов.
- В отличие от модели водопада, в гибкой модели для старта проекта достаточно лишь небольшого планирования.
3. «Incremental Model» (инкрементная модель)
В инкрементной модели полные требования к системе делятся на различные сборки. Терминология часто используется для описания поэтапной сборки ПО. Имеют место несколько циклов разработки, и вместе они составляют жизненный цикл «мульти-водопад». Цикл разделен на более мелкие легко создаваемые модули. Каждый модуль проходит через фазы определения требований, проектирования, кодирования, внедрения и тестирования. Процедура разработки по инкрементной модели предполагает выпуск на первом большом этапе продукта в базовой функциональности, а затем уже последовательное добавление новых функций, так называемых «инкрементов». Процесс продолжается до тех пор, пока не будет создана полная система.
Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы. В наших проектах мы применяли ее для создания читалки DefView, а следом и сети электронных библиотек Vivaldi.
Как пример опишем cуть одного инкремента. Сеть электронных библиотек Vivaldi пришла на смену DefView. DefView подключалась к одному серверу документов, а теперь может подключаться ко многим. На площадку учреждения, желающего транслировать свой контент определенной аудитории, устанавливается сервер хранения, который напрямую обращается к документам и преобразует их в нужный формат. Появился корневой элемент архитектуры — центральный сервер Vivaldi, выступающий в роли единой поисковой системы по всем серверам хранения, установленным в различных учреждениях.
Когда использовать инкрементную модель?
- Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени.
- Требуется ранний вывод продукта на рынок.
- Есть несколько рисковых фич или целей.
6. «Iterative Model» (итеративная или итерационная модель)
Итерационная модель жизненного цикла не требует для начала полной спецификации требований. Вместо этого, создание начинается с реализации части функционала, становящейся базой для определения дальнейших требований. Этот процесс повторяется. Версия может быть неидеальна, главное, чтобы она работала. Понимая конечную цель, мы стремимся к ней так, чтобы каждый шаг был результативен, а каждая версия — работоспособна.
На диаграмме показана итерационная «разработка» Мона Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй — появляются цвета, а третья итерация добавляет деталей, насыщенности и завершает процесс. В инкрементной же модели функционал продукта наращивается по кусочкам, продукт составляется из частей. В отличие от итерационной модели, каждый кусочек представляет собой целостный элемент.
Примером итерационной разработки может служить распознавание голоса. Первые исследования и подготовка научного аппарата начались давно, в начале — в мыслях, затем — на бумаге. С каждой новой итерацией качество распознавания улучшалось. Тем не менее, идеальное распознавание еще не достигнуто, следовательно, задача еще не решена полностью.
Когда оптимально использовать итеративную модель?
- Требования к конечной системе заранее четко определены и понятны.
- Проект большой или очень большой.
- Основная задача должна быть определена, но детали реализации могут эволюционировать с течением времени.
1. «Waterfall Model» (каскадная модель или «водопад»)
Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.
С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ. Проекты, о которых написано на Хабре: средний — рентгеновский микротомограф, мелкий — автообновление службы Windows на AWS.
Когда использовать каскадную методологию?
- Только тогда, когда требования известны, понятны и зафиксированы. Противоречивых требований не имеется.
- Нет проблем с доступностью программистов нужной квалификации.
- В относительно небольших проектах.
7. «Spiral Model» (спиральная модель)
«Спиральная модель» похожа на инкрементную, но с акцентом на анализ рисков. Она хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации.
Спиральная модель предполагает 4 этапа для каждого витка:
- планирование;
- анализ рисков;
- конструирование;
- оценка результата и при удовлетворительном качестве переход к новому витку.
4. «RAD Model» (rapid application development model или быстрая разработка приложений)
RAD-модель — разновидность инкрементной модели. В RAD-модели компоненты или функции разрабатываются несколькими высококвалифицированными командами параллельно, будто несколько мини-проектов. Временные рамки одного цикла жестко ограничены. Созданные модули затем интегрируются в один рабочий прототип. Синергия позволяет очень быстро предоставить клиенту для обозрения что-то рабочее с целью получения обратной связи и внесения изменений.
Модель быстрой разработки приложений включает следующие фазы:
- Бизнес-моделирование: определение списка информационных потоков между различными подразделениями.
- Моделирование данных: информация, собранная на предыдущем этапе, используется для определения объектов и иных сущностей, необходимых для циркуляции информации.
- Моделирование процесса: информационные потоки связывают объекты для достижения целей разработки.
- Сборка приложения: используются средства автоматической сборки для преобразования моделей системы автоматического проектирования в код.
- Тестирование: тестируются новые компоненты и интерфейсы.
Может использоваться только при наличии высококвалифицированных и узкоспециализированных архитекторов. Бюджет проекта большой, чтобы оплатить этих специалистов вместе со стоимостью готовых инструментов автоматизированной сборки. RAD-модель может быть выбрана при уверенном знании целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев.
Подытожим
На слайде продемонстрированы различия двух наиболее распространенных методологий.
В современной практике модели разработки программного обеспечения многовариантны. Нет единственно верной для всех проектов, стартовых условий и моделей оплаты. Даже столь любимая всеми нами Agile не может применяться повсеместно из-за неготовности некоторых заказчиков или невозможности гибкого финансирования. Методологии частично пересекаются в средствах и отчасти похожи друг на друга. Некоторые другие концепции использовались лишь для пропаганды собственных компиляторов и не привносили в практику ничего нового.
2. «V-Model»
Унаследовала структуру «шаг за шагом» от каскадной модели. V-образная модель применима к системам, которым особенно важно бесперебойное функционирование. Например, прикладные программы в клиниках для наблюдения за пациентами, интегрированное ПО для механизмов управления аварийными подушками безопасности в транспортных средствах и так далее. Особенностью модели можно считать то, что она направлена на тщательную проверку и тестирование продукта, находящегося уже на первоначальных стадиях проектирования. Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты.
Пример нашей работы на основе V-методологии — мобильное приложение для европейского сотового оператора, который экономит расходы на роуминг во время путешествий. Проект выполняется по четкому ТЗ, но в него включен значительный этап тестирования: удобства интерфейса, функционального, нагрузочного и в том числе интеграционного, которое должно подтверждать, что несколько компонентов от различных производителей вместе работают стабильно, невозможна кража денег и кредитов.
Когда использовать V-модель?
- Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
- Для малых и средних проектов, где требования четко определены и фиксированы.
- В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.
Читайте также: