Определение бизнес требований для развертывания приложений

«Application packaging» устоявшийся термин для названия IT сервиса в сфере поддержки конечных пользователей (EUS) во всем мире, но, практически не известный в России. Поэтому в нашей статье опишем лучшие практики, которые скрываются за данным сервисом и расскажем о том, как он может помочь снизить общую стоимость владения (TCO) программным обеспечением и, в конечном счете, уменьшить стоимость поддержки рабочих мест пользователей.

Стратегия и подходы. Снижение TCO.

Стоимость владения программным обеспечением (ПО) занимает существенную долю IT-бюджета любой современной компании, что обуславливает актуальность управления (подходами, стратегией и т.д.) как бюджетом, так и программами с целью снижения стоимости поддержки рабочих мест пользователей. Один из таких проверенных временем подходов – это Application packaging (рус. авторский перевод «Подготовка приложений к развертыванию»).

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

• Возможность установки в тихом режиме (silent) для того, чтобы не отвлекать пользователя от работы.
• Отключение обновлений для минимизации траффика и контроля используемых версий программ (и минимизации количества разнородных версий, что удорожает обслуживание программ)
• Установка строго без перезагрузок и выключений компьютера, чтобы не прерывать работу конечных пользователей, даже в самых сложных ситуациях, когда того требует разработчики программного обеспечения.
• Автоматическое удаление предыдущей версии программного обеспечения на уровне пакета для минимизации усилий по развертыванию.
• И сотни других практик….

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

ROI (Return of investments)

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

Так, например, в статье JUKKA KOULETSIS: The Basics of Application Packaging приводится опыт компании Dell, где утверждается, что использование практик (сервиса) по подготовке программ к развертыванию позволяет единожды вложившись в разработку и тестирование пакета, сократить стоимость их поддержки:

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

В производственном секторе мы работаем с двумя компаниями (европейскими подразделениями), изготавливающими шины. Это мировые лидеры (из ТОП-10) с более 10 тыс. рабочих станций. Только за счет использования практик application packaging нам удалось довести состав команды развертывания до 1 человека (без учета бекапов). Другими словами, мы смогли компенсировать 80% затрат на подготовку приложений уже на этапе развертывания, при этом на начальном этапе количество инцидентов, связанных с приложениями, удалось сократить на 45% соответственно:

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

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

Технологии и решения

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

Самой известной технологией является Microsoft Windows Installer — подсистема Microsoft Windows, обеспечивающая установку программ в специальном формате .msi. В отличие от неконтролируемых и неуправляемых setup.exe технология предоставляет ряд преимуществ, которые делают ее крайне популярной:

• процесс установки можно контролировать стандартными политиками ОС Windows;
• информация об устанавливаемых программах содержится в структурированном виде (база данных) и cab архивах, что обеспечивает прозрачность (в том числе для антивирусов);
• возможно самовосстановление при повреждении отдельных ресурсов, что сокращает количество инцидентов;
• возможность принудительного восстановления, что сокращает время на восстановление работоспособности приложения, в случае потери целостности;
• возможность преактивного выявления конфликтов между приложениями и их устранение,
• и т.д.

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

Поэтому в определённых ситуациях становиться выгодной конвертация установочных файлов формата Exe (Setup.exe) в формат Windows Installer. Для этих целей мы используем решение AdminStudio Repackager от Flexera Software.

На сегодняшний день все большую популярность получают технологии виртуализации программ, в частности, решение AppV от Microsoft, которой мы посвятили отдельную статью на Хабре. Технологии виртуализации с каждым годом завоевывают все большую популярность. Уже на сегодняшний день половина наших крупных европейских заказчиков используют AppV как основную технологию, а Windows Installer применяют там, где не применим AppV. Последний особенно выгоден, где повсеместно используются терминальные среды. Для них Application packaging за счет управления конфликтами (проактивного поиска и устранения) и проактивного анализа возможности использования на терминальных средах позволяет не только получить все плюсы, описанные выше, но и более рационально использовать физические сервера, сократить количество ребилдов серверов и общее количество инцидентов и проблем, то есть снизить стоимость владения до 25% процентов. Для управления конфликтами (conflict management) мы используем свои разработки, а также решение Application Manager от Flexera Software.

Более того, использование сервисов по подготовке приложений к развертыванию позволяет существенно снизить риски и стоимость миграций в новые среды (например, из десктопных решений на терминальные или на новую ОС). Так, сейчас мы активно работаем над миграцией наших некоторых клиентов на Windows 10. И для тех заказчиков, где уже используется Application packaging – мы делаем эту работу за считанные недели/месяцы в зависимости от размера компании. Там же, где Application packaging еще не используется, время миграции – это самый лучший период для внедрения сервиса, попутно проведя оптимизацию состава программного обеспечения, что по факту может сэкономить в разы только бюджет на миграцию, не говоря уже о дальнейшей стоимости поддержки. О том, какие программы используются для рационализации, чуть ниже в этом материале.

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

• Colibri tracker – решение позволяет нам управлять процессом подготовки приложений к развертыванию, а также поддерживать проекты по миграции операционных систем, приложений и т.д. Помимо трекинга задач (программ/пакетов) по жизненному циклу, в данной утилите реализована конвейерная автоматизация и интеграция с ITSM системами, системами развертывания (SCCM / Altiris и т.д.) и другим ПО (в том числе приведенным в данной статье), которая позволяет нам сократить временные издержи на 45% и предложить оптимальные цены для наших заказчиков за счет слаженности, гибкости, синергии в управлении работами: Colibri предоставляется нами также как SaaS решение.
• Inventory Intelligence portal. Чтобы что-то сделать лучше, необходимо сперва понять «как есть» сейчас и подумать «где и что» можно рационализировать. Данная программа использует результаты работы утилит для инвентаризации (от Microsoft, Lakeside) и помогает проводить «интеллектуальный» анализ:
  1. исключить неиспользуемый и забытый софт;
  2. исключить программы с одинаковым назначением, сделав выбор в пользу наиболее оптимальных;
  3. понять, где можно использовать меньшее количество лицензий, чем было закуплено ранее или планировалось закупить.

  

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

• CaptureTool. Данный тул мы предлагаем нашим заказчикам, чтобы упростить сбор требований для ПО и формирования документа с требованиями: набор настроек при установке, после установки. Единственное что нужно сделать – запустить утилиту, нажать кнопку «старт», установить программу, настроить ее и нажать кнопку «финиш».

  

  Сгенерированный документ пользователь может дополнить специфичными требованиями (пожелания по платформе и т.д.). Кроме того, при необходимости, программа просканирует наиболее важные логи системы, ключи реестра, составит график загрузки памяти/процессора (RAM / CPU). В дальнейшем данная информация может использоваться для того, чтобы принять решение о способе доставки приложения (тонкий/толстый клиент, необходимость виртуализации, система развертывания или AD и т.д.).
• AppPortal — еще одно наше решение, которое позволяет пользователям самостоятельно заказывать программы, которые немедленно будут доставлены пользователю на его компьютер. Результат – пользователи счастливы, минимальное вовлечение службы поддержки (а точнее отсутствие потраченного времени, если не считать поддержку самого AppPortal).

  

Совокупность решений сторонних вендоров и наших решений позволяет нам оказывать сервисы на высоком уровне даже для зрелых IT-инфраструктур за адекватную стоимость.

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

Хотели бы Вы использовать Application packaging в своей компании:

Проголосовали 11 пользователей.

Воздержались 10 пользователей.

Для удовлетворения общих требований к разработке — снижения затрат путем повышения продуктивности труда разработчиков и уменьшения сложности разработки, не в ущерб качеству конечного продукта — традиционно используются интегрированные среды разработки (integration development environment, IDE), предоставляющие базовые инструменты. Однако за их пределами остаются ключевые этапы жизненного цикла приложений, такие как определение требований, моделирование, тестирование, развертывание и управление изменениями. Поддерживающие эти этапы инструменты, как правило, изолированы друг от друга. В результате группы специалистов, отвечающие за разные задачи в проекте — бизнес-аналитики, архитекторы, программисты, тестировщики — работают разрозненно. Как отмечают в Meta Group [1], подобное состояние вполне соответствует традиционной методологии разработки, когда отдельные процессы идут последовательно друг за другом, но отнюдь не отвечает современным требованиям повышения продуктивности и сокращения затрат. Метод «водопада», как правило, удлиняет время реализации программного проекта, приводит к превышению бюджета и не способствует созданию продукта, отвечающего ожиданиям заказчика. Это своего рода производственный конвейер, рассчитанный на массовый выпуск однотипной продукции.

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

Цикличному ходу разработки больше подходят итеративные методики, подразумевающие постоянное сотрудничество между разными функциональными группами в команде программного проекта и конечными пользователями и тесную взаимосвязь между разными этапами жизненного цикла приложения. Однако для эффективной реализации итеративных принципов нужны интегрированные среды совсем иного качества. Концепцию такой среды предлагает, в частности, компания Borland, которая в результате развития собственных разработок и приобретения целого ряда компаний представила пакет интегрированных систем, реализующих управление полным жизненным циклом приложений (Application Life Cycle Management, ALM).

Жизненный цикл программного продукта

Рис. 1. Жизненный цикл приложений и его реализация с помощью продуктов Borland

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

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

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

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

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

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

Цементирует все этапы в жизненном цикле процесс управления изменениями, который обеспечивает координацию действий между членами различных групп единой команды проекта. Здесь применяются системы управления конфигурацией программного обеспечения (software configuration management, SCM), в чьи функции входит централизованное хранение данных по проекту, контроль версий, управление внесением изменений в проект и т.д.

Определение требований

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

По определению IEEE [2], требование — это «условие или возможность, необходимые пользователю для решения той или иной проблемы или достижения той или иной цели». Управление требованиями определяется аналитиками Meta Group [3] как процесс, гарантирующий, что все специалисты, вовлеченные в проект разработки, знают об определенных требованиях к программному продукту и реализуют процессы, позволяющие эти требования удовлетворить. При всей очевидности того, какое значение имеет четкое задание требований для получения качественного конечного продукта и повышения продуктивности участников разработки, этот этап — и тем более его поддержка с помощью специальных автоматизированных средств — далеко не всегда реализуется со всей необходимой тщательностью. Разработчики часто избегают формализации требований как лишней бюрократической нагрузки, мешающей главному, по их мнению, процессу — собственно программированию. Заказчики также не всегда готовы формализовать и детализировать свои проблемы, полагая, что общей постановки задачи достаточно для того, чтобы разработчики поняли их нужды. Обе стороны заблуждаются. Формальное определение требований со стороны заказчика помогает ему прояснить свои потребности и избежать неясностей в толковании постановки задачи разработчиками. Последние, в свою очередь, получают большую свободу в выборе средств и методов реализации, когда задача понятна до деталей.

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

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

По данным Meta Group, 75% инсталляций систем управления требованиями принадлежит Borland, IBM Rational и Telelogic. При этом все три компании — относительные новички на этом рынке, поскольку решения по управлению требованиями были приобретены ими за последние два года. Так, система CaliberRM стала частью семейства продуктов Borland в результате покупки компании Starbase. В CaliberRM формируются шаблоны для наборов требований заказчика, которые собираются в центральном репозитории. Система предоставляет встроенную поддержку обсуждения требований различными участниками процесса. Права доступа к данным требований, привилегии и ответственность пользователей определяются в системе на ролевой основе.

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

Система обеспечивает экспорт данных в таблицы MS Access и импорт из Word, но пока не поддерживает обмен данными на базе XML Metadata Interchange. Табличное представление требований упрощает их сортировку и задание приоритетов в зависимости от затрат на реализацию и значимости. Для каждого требования реализуется независимый контроль версий. Предоставляются глоссарии для определения специфичных для отрасли, проекта или компании терминов с целью избежать нечеткости определения и двусмысленности толкования требований. CaliberRM поддерживает различные методы визуализации зависимостей между требованиями, с помощью которых пользователь может ограничить область анализа, необходимого в случае изменения того или иного требования. Имеется модуль, который использует данные требования для оценки трудозатрат, рисков и расходов, связанных с реализацией требований.

CaliberRM обеспечивает функциональную (на базе прикладных интерфейсов) интеграцию с другими ALM-решениями Borland — системой конфигурационного управления StarTeam и средой моделирования Together, что позволяет отслеживать влияние изменений в требованиях на исходный код и гарантировать соответствие архитектуры системы задачам заказчика. Интеграция системы со средствами тестирования компании Mercury Interactive обеспечивает быстрый выбор необходимых тестовых испытаний для проверки выполнения заданных и измененных требований, а возможность экспорта данных в систему календарного планирования MS Project — отображение требований как задач проекта.

Анализ и проектирование

На следующем этапе проектирования разработчики отвечают на вопрос «Как должна быть построена система, чтобы реализовать определенные на предыдущем этапе требования». Признанным стандартом моделирования архитектуры объектно-ориентированных приложений сегодня стал язык UML. В системах проектирования на базе UML создаются диаграммы, которые в совокупности представляют единую концепцию программного продукта. Затем набор диаграмм переводится в конкретный язык программирования. Помимо разработки архитектуры новых приложений, средства проектирования позволяют создавать визуальные представления существующих систем и анализировать их внутреннюю структуру для повышения эффективности внесения изменений в такие программы. Безусловно, наиболее известным решением в области UML-проектирования остается система Rational Rose.

В результате приобретения компании TogetherSoft, Borland стала обладательницей собственной серии продуктов Together для анализа и проектирования. Центральной в этом семействе является интегрированная многоязыковая среда проектирования и разработки ControlCenter, поддерживающая визуальное моделирование на UML приложений как для платформы J2EE с последующим написанием кода на Java, так и для платформы .Net на языках С#, C++ и Visual Basic .Net. Кроме базовой версии доступен экономичный вариант системы для индивидуальных разработчиков и небольших групп (Together Solo), а также редакции для платформы IBM WebSphere, для интегрированной среды разработки Jbuilder и для открытой среды Eclipse.

Together ControlCenter реализует генерацию исходных кодов по последовательности UML-диаграмм. В системе реализована технология LiveSource, которая обеспечивает синхронизацию между проектом приложения и изменениями — при внесении изменений в исходные тексты меняется модель программы, а при изменении модели надлежащим образом изменится текст на языке программирования. Все это происходит в реальном времени и исключает необходимость вручную модифицировать модель или переписывать коды. Наличие подобных возможностей наряду с соответствием стандарту UML в Aberdeen Group [4] считают ключевыми критериями выбора эффективной системы моделирования. Контроль версий осуществляется благодаря функциональной интеграции решений Together и системы StarTeam. Также поддерживается интеграция с системой конфигурационного управления Rational ClearCase. Помимо проектирования и разработки компонентных приложений для платформ J2EE и .Net, ControlCenter поддерживает визуальное XML-моделирование, моделирование бизнес-процессов, разработку Web-сервисов и баз данных.

Важной особенностью систем семейства Together является то, что они предоставляют средства автоматизированного инспектирования исходных кодов для повышения качества архитектуры и реализации программ. Сюда относятся средства аудита и оценки программ на базе метрик, дополняющие традиционные способы проверки кода вручную. Как отмечается в [5], проверка кода (code review) как важнейший инструмент повышения качества разрабатываемого продукта не теряет своей актуальности и в «быстрых» методиках. Скажем, в ХР проверка кода является непрерывным процессом, поскольку экстремальное программирование обязывает работать над исходными текстами в парах. Обычно результатом проверки кода становится рефакторинг (refactoring), т.е. изменение внутренней структуры программы с целью упрощения ее понимания и снижения затрат на модификацию.

Проверка кода является частью процесса инспектирования программных средств — оценка программного продукта, в ходе которой группа специалистов, среди которых не должно быть автора программы, проверяет требования, архитектуру или код программы с целью выявить ошибки, нарушения корпоративных стандартов и другие проблемы [2]. Что касается проверки кода, то она не только способствует тому, что программа становится более понятной и простой в сопровождении, но и позволяет повышать квалификацию новых специалистов в команде разработчиков. Определенная часть этой работы, например, оценка уровня реализации бизнес-логики программы, остается за человеком. Но для целого ряда функций автоматизация способна значительно повысить эффективность и продуктивность процесса проверки. Например, в компании TogetherSoft четырем специалистам было поручено провести в течение 15 минут аудит небольшого фрагмента программы на Java. За это время ими было выявлено 21 нарушение, в то время как средствами ControlCenter в том же фрагменте исходного кода всего за 2 секунды было обнаружено 150 несоответствий принятым стандартам программирования на Java [5].

Аудит — статическая проверка исходного кода программы с целью нахождения несоответствий принятым в организации стандартам использования языка программирования. В ControlCenter для языков Java и С++ реализованы такие категории аудита исходного кода, как стиль кодирования, критические ошибки моделирования, документирование, именование, производительность, общие ошибки использования языка, чрезмерный объем кода, ошибки в использовании EJB и др.

Более «тонкой материей» в процессе проверки кода является оценка на базе метрик. Если аудит сосредоточен главным образом на синтаксическом анализе текста программы, то метрики позволяют оценить уровень ее объектной архитектуры. Метрики — это точные количественные данные, на основе которых оцениваются размер, сложность и зависимости в тексте программы, а реализация метрик — попытка подвести математическую основу под такую расплывчатую категорию, как качество программы. Оценка на базе метрик позволяет устранить нарушения базовых принципов объектно-ориентированной разработки и провести эффективный рефакторинг программы. Сбор и анализ метрик — крайне трудоемкая задача, поэтому оценка на базе метрик только выигрывает от автоматизации. Together обеспечивает анализ на базе метрик для таких категорий, как базовые эвристики, зависимости, связи, инкапсуляция, размер программы, наследование, соотношение комментариев и т.д., для языков программирования Java, C++, C#, Visual Basic 6 и VB.Net.

Разработка

В течение почти всей своей 20-летней истории деятельность Borland была сосредоточена именно на создании сред разработки, причем отличительной чертой этой компании был стабильный нейтралитет в отношении платформ — Borland предлагала инструментарий как для Java (JВuilder), так и для Windows (Delphi, C++Builder). Принципиальная позиция этой «Швейцарии» в мире разработки получила логическое продолжение в выпуске новых систем для платформы .Net.

Основные усилия по совершенствованию сред разработки Borland сосредотачивает сегодня на интеграции с другими этапами жизненного цикла приложений, прежде всего, с решениями по анализу и проектированию Together. Уже упоминалась редакция Together для системы JВuilder, которая обеспечивает разработку компонентных приложений на платформе J2EE. Связь со средствами моделирования программ реализована и в новой среде разработки C#Builder для платформы .Net Framework, которая имеет также возможности интеграции с системами тестирования и средствами развертывания приложений.

C#Builder — среда разработки на языках С# и Visual Basic .Net. Одно из ключевых свойств этой системы — предоставление единого интерфейса для работы с разными базами данных. В C#Builder поддерживаются драйверы доступа к данным из ADO.Net, но их возможности существенно расширены с помощью модуля Borland Data Provider (BDP). Пользователь выполняет все операции с данными и SQL-запросы с помощью общего для всех разновидностей баз данных интерфейса Data Explorer, а BDP осуществляет автоматическое преобразование типов данных .Net в типы для различных баз данных, включая Oracle 9i, IBM DB2, Microsoft SQL Server 2000, Borland InterВase. C#Builder включает широкий спектр технологий, необходимых для работы распределенных приложений: Web-сервисы, компонентные среды СОМ+ и .Net Remoting, а также CORBA и EJB, для которых используются механизмы еще одной новой разработки Borland — системы Janeva.

C#Builder поддерживает новую парадигму разработки, определяемую проектированием (design-driven development), известную также под названием МDA (model-driven architecture). Спецификации MDA разработаны консорциумом OMG [6], а Borland одной из первых реализовала MDA в конкретном инструментарии. Речь идет о системе Enterprise Core Objects (ECO), которая позволяет без программирования получить работающую программу для .Nеt непосредственно по UML-модели, созданной средствами Together или импортированной из другой системы моделирования с помощью механизмов XMI. На C# пишется только пользовательский интерфейс. Усилия разработчиков могут быть сосредоточены на бизнес-логике и ее воплощении в модели, а программу на C# они даже не видят.

Тестирование и профилирование

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

Рис. 2. Стоимость исправления недостатков производительности на разных стадиях жизненного цикла

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

Серия соответствующих инструментальных средств появилась в составе пакета поддержки жизненного цикла от Borland в результате покупки компании Optimizeit. В семейство продуктов контроля производительности входят Optimizeit Suite 5, Optimizeit Profiler for .NET и Optimizeit ServerTrace. Первые две системы позволяют до развертывания системы выявить потенциальные проблемы использования аппаратных ресурсов — памяти и процессорных мощностей на платформах J2EE и Microsoft .Net соответственно. Интеграция Optimizeit Suite 5 в среду разработки Jbuilder, а Optimizeit Profiler — в C#Builder и Visual Basic .Net позволяет проводить контрольные испытания приложений по мере разработки и ликвидировать узкие места производительности с наименьшими затратами. Система Optimizeit ServerTrace предназначена для управления производительностью серверных J2EE-приложений с точки зрения достижения заданного уровня обслуживания и сбора контрольных данных по виртуальным Java-машинам.

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

Средства профилирования семейства Borland Optimizeit интегрированы с системой нагрузочного тестирования LoadRunner от Mercury Interactive. Кроме того, в среду разработки JВuilder интегрирован продукт Mercury ТestDirector для управления скриптами тестирования.

Развертывание

У того, кто ведет разработку на Java, есть широкие возможности выбора сервера приложений для развертывания готовой системы, в частности, Borland предлагает сервер приложений Enterprise Server: AppServer Edition для J2ЕЕ-приложений и Web-сервисов; VisiBroker Eition для распределенных приложений в гетерогенной среде, требовательных к времени отклика и ориентированных на инфраструктуру CORBA; Web Edition для Web-приложений.

Для платформы .Net выбор среды развертывания ограничен, и, хотя компьютерный мир все более склоняется к мысли, что война между J2EE и .Net не имеет смысла — каждая из платформ найдет свою нишу применения. Компании, ведущие свой бизнес в сфере финансов или телекоммуникаций, уже сделали значительные инвестиции в приложения на базе J2EE и CORBA, поскольку эти среды гарантируют масштабируемость, безопасность и высокую производительность транзакций. С другой стороны, в тех же организациях может возникнуть интерес к использованию .Net на уровне фронт-офиса. Вполне жизненна ситуация, когда новые приложения для .Net должны внедряться в корпоративную инфраструктуру, давно и успешно использующую технологии J2EE и CORBA. Интеграция двух сред с помощью Web-сервисов не эффективна, если речь идет о компонентах одной прикладной системы, поскольку Web-сервисы больше рассчитаны на взаимодействие слабо связанных приложений и не обеспечивают быстрого и надежного транспорта для передачи данных. Развитие протокола SOAP в сторону обеспечения более высокой производительности и защищенности передачи не изменит его сути, которая не позволяет реализовать на базе Web-сервисов тесную интеграцию, необходимую для многих приложений и поддерживаемую CORBA. Предлагаются и технологии специальных «мостов» между двумя платформами, но для них, как правило, требуются дополнительные аппаратные и программные ресурсы. Кроме того, такие мосты порождают точки потери производительности и отказа системы.

Для Borland отсутствие приверженности отдельно взятой платформе или стеку протоколов — почти религиозный принцип. Очередной важный шаг на этом пути состоит в выпуске продукта, обеспечивающего прозрачную совместимость приложений для .Net с инфраструктурами J2EE и CORBA. Речь идет о системе Janeva.

Janeva предоставляет клиентским и серверным программам для .NET возможность обращаться к гетерогенным серверным компонентам J2EE и CORBA, причем совершенно прозрачно для разработчика этих программ и не требуя использования дополнительных аппаратных или программных ресурсов (см. рис. 3). Janeva включает компиляторы Java-to-C# и CORBA IDL-to-C#, которые автоматически генерируют коммуникационные элементы — стабы (stubs) и сборки (assemblies) на языке C#. Тем самым обеспечивается возможность обращения к .Net из Java-программ и объектов CORBA. Кроме того, Janeva предоставляет библиотеки времени выполнения, которые вызываются .Net-приложением для преобразования удаленных вызовов этой платформы в вызовы по IIOP (Internet Intеr-ORB Protоcol) — производительному, масштабируемому и защищенному протоколу для связи распределенных компонентов в среде CORBA. Таким образом, пользователь Janeva продолжает работать в привычной среде .Net, используя интерфейсы, процедуры определения свойств и вызова методов и типы данных, и при этом получает доступ к объектам CORBA и компонентам EJB. В результате совместимость двух платформ достигается минимальными усилиями и практически без риска для проекта. Janeva поддерживает Microsoft Common Language Runtime, поэтому может быть использована для любого языка программирования, совместимого с CLR, включая C#, J#, Visual Basic .Net и Visual C++ .Net.

Рис. 3. Интеграция платформ средствами Janeva

В целом, Borland предлагает три основные возможности интеграции для развертывания разнородных систем:

• интеграция низкого уровня на базе технологий Janeva;
• создание модели бизнес-системы и затем разработка компонентов этой системы для разных платформ. Поскольку среда проектирования Together позволяет генерировать исходные тексты программ как на C#, так и на Java, на основе одной UML-модели с помощью средств Together можно создавать прикладные компоненты для разных платформ.

Координация и управление изменениями

В системе управления конфигурациями и изменениями сосредоточена сущность концепции ALM: именно она объединяет основные фазы жизненного цикла приложения и интегрирует продукты, эти фазы поддерживающие, поэтому управление изменениями вместе с системой StarTeam расположено в центре круговой диаграммы управления жизненным циклом «от Borland» (рис. 1).

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

StarTeam предоставляет централизованный репозиторий для хранения и совместного использования членами проектной группы информационных активов проекта, которые привязываются к соответствующим инструментальным средствам и процессам жизненного цикла. Система обеспечивает доступ к актуальной информации по проекту тем членам группы, которым она предназначена, осуществляя контроль прав доступа на разных уровнях — от проекта в целом вплоть до отдельного ресурса. Система управляет потоком запросов на изменения, выставляет приоритеты и исключает дублирование, проверяет выполнение изменений и обеспечивает генерацию сообщений ответственным за изменение членам проектной команды. StarTeam предоставляет возможности управления задачами, обеспечивая назначение работ определенным группам специалистов в проектной команде. Например, завершение разработки некоторой части приложения будет отражено в подсистеме управления изменениями, затем StarTeam выдаст задание на проведение соответствующих тестов. Этот компонент системы интегрирован с MS Project. Кроме того, в StarTеam формируется база знаний о проблемах, которая используется членами команды во время проведения централизованных дискуссионных форумов.

StarTeam совместима с интерфейсом Microsoft Source Code Control и легко интегрируется с любой системой разработки, которая поддерживает этот API. Кроме того, в системе реализованы средства интеграции со средами разработки и моделирования Together, JBuilder, Delphi, C++Builder и C#Builder.

Виды интеграции

Концепцию управления жизненным циклом приложения невозможно реализовать без интеграции инструментальных средств, используемых на разных этапах. Стратегическая задача Borland на ближайшие несколько лет — обеспечить полную прозрачность и отслеживаемость всех процессов разработки в течение жизненного цикла; она решается путем интеграции всех систем в полное ALM-решение [7]. Уже сегодня многие системы Borland имеют развитые возможности взаимосвязи не только друг с другом, но и с системами других поставщиков. Так, совместная работа системы проектирования Together с системой согласования требований CaliberRM позволяет рассматривать в процессе проектирования только те функции, которые предусмотрены на этапе определения требований. Интеграция Together Edition for Jbuilder и IDE Jbuilder обеспечивает непосредственное отображение изменений UML-модели в тексте программы. Аналогичные возможности существуют для среды IBM WebSphere. Система StarTeam управляет этими изменениями, а новые редакции инструментов Borland для платформы .Net позволяют использовать в качестве среды разработки не только C#Builder, но и Visual Studio .Net.

В Borland выделяют три уровня интеграции. Большинство реализованных сегодня возможностей взаимосвязи систем основано на принципах «функциональной» (touch-point) интеграции, которая позволяет обратиться из одной системы к функциям другой, выбрав соответствующий пункт меню. Например, интерфейс управления изменениями StarTeam непосредственно отображается в системе проектирования Together и системах разработки C#Builder и Visual Studio .Net. Такая интеграция дает возможность разделять информацию между системами, но не обеспечивает единого рабочего пространства, вынуждает пользователя переключать окна и подчас приводит к дублированию процессов управления структурой проекта.

Более перспективны высокие уровни интеграции. «Встроенная» (embedded) интеграция обеспечивает работу с окном одной системы, находясь при этом в другой. Например, не выходя из среды разработки Jbuilder можно просматривать графики производительности, которые создает система испытаний Optimizeit. И наконец, самый высокий уровень интеграции — «синергетический» (synergistic), позволяющий прозрачно сочетать функции двух различных продуктов, так чтобы разработчики даже не замечали, что работают с разными системами. Для большинства решений Borland и других поставщиков синергетическая интеграция — дело будущего, однако ее принципы уже реализованы с помощью технологий Janeva. Janeva обеспечивает взаимное конвертирование между платформами J2EE и .Net, так что программные продукты для .Net могут напрямую использовать компоненты на Java, при этом от разработчиков таких приложений не требуется знаний в области объектных технологий CORBA и EJB.

***

По прогнозам IDC [8], рынок средств разработки и развертывания приложений, испытавший определенный кризис в 2002 году, в ближайшее пятилетие ожидает устойчивый рост в среднем на 6,3% в год. Определяющим фактором для развития этой положительной тенденции является стремление компаний-разработчиков повысить продуктивность своей работы, сократить сроки вывода новых продуктов на рынок, контролировать расходы и быстро получать отдачу на сделанные инвестиции. Инструментом для достижения этих целей становится использование сред разработки, позволяющих снизить сложность процессов создания программных продуктов, увеличить их эффективность, уменьшить затраты на разработку и максимально использовать потенциал новых технологий. Аналитики сходятся на том, что основное направление развития инструментальных средств — их сквозная интеграция, переход от сред к интегрированным пакетам, объединяющим возможности определения требований, моделирования, разработки, тестирования, управления изменениями и развертывания приложений. В ближайшие годы такие пакеты поддержки жизненного цикла, помимо перечисленных возможностей будут включать в себя средства управления потоками работ и проектами. Рынок таких инструментальных средств ожидает глобальная консолидация, обещающая принести значительные выгоды разработчикам.

Литература

1. T. Murphy, Accelerating J2EE Application Delivery. Meta Group White Paper, June 2003.
2. IEEE Standard Glossary of Software Engineering Terminology, 1997.
3. T. Murphy, Mastering the requirements of requirements management. Meta Group, April 2003.
4. W. Kernochan, Design-driven development: good only if done well. Aberdeen Group, March 2003.
5. R.C. Gronback, Software remodeling: improving design and implementation management. TogetherSoft, 2002.
6. R. Soley and the OMG Staff Strategy Group, Model Driven Architecture. OMG White Paper, November 2000.
7. Наталья Дубова, Управление жизненным циклом приложений. Интервью с Дэвидом Интерсимоном. // Открытые системы, 2003, № 6.
8. Worldwide application development and deployment forecast summary, 2003-2007. IDC, March 2003.

---

В методологии Rational Unified Process (RUP), предложенной компанией Rational Software, определяются пять уровней зрелости управления требованиями:

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

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

---

MDA

Вся эволюция программирования, основанная на стремлении снизить сложность и повысить продуктивность процессов разработки, сопровождалась повышением уровня абстракции написания программ — от машинных кодов к ассемблеру, от ассемблера к высокоуровневым языкам. Предложенный OMG подход MDA (model-driven architecture) позволяет при создании приложений сконцентрироваться на создании абстрактной бизнес-модели, практически полностью автоматизировав ее перевод в коды на базе конкретной инфраструктуры промежуточного слоя — CORBA, EJB, COM+, .Net и т.д.

Рис. Три этапа реализации Model-Driven Architecture

Разработка в соответствии с принципами MDA проходит в три этапа (рис.4). На первом создается полностью независимая от среды разработки и платформы визуальная UML-модель, описывающая бизнес-логику будущего приложения (доменная модель). Для ее формирования стандарт OMG MDA предоставляет несколько базовых моделей, описывающих структуру определенной бизнес-среды, например, базовая модель Enterprise Computing с компонентной структурой и взаимодействием на основе транзакций или модель Real-Time Computing с специальными механизмами контроля ресурсов. На следующем этапе абстрактная модель «конкретизируется», преобразуясь в UML-модель приложения для определенной платформы. Модель приложения включает специфические для данной архитектуры элементы построения и интеграции прикладных систем, сохраняя семантику доменной модели. Третий этап завершает трансформацию модели в коды программы. Для автоматизации последовательного преобразования модели от этапа к этапу используются шаблоны, отображающие специфику технологической платформы и языка реализации приложения.

Формирование логики приложения на самом высоком уровне абстракции и автоматическая генерация всех элементов, связанных с платформой реализации приложения способствуют сокращению сроков проектирования, тестирования и развертывания, полностью исключая затраты времени и сил на кодирование. Последнее обстоятельство гарантирует высокое качество кода. Примеры реализации MDA — системы Compuware OptimalJ и Borland ECO.

---

«Живое» программирование

Требования рынка заставляют ускорять циклы разработки, но не позволяют снижать качество. Необходимость делать все быстро подчас вынуждает отказываться от следования строго документированным процессам разработки, однако отсутствие четкой организации труда отрицательно сказывается на продуктивности команды и, в итоге, на конечном результате их работы. Поиск компромисса между сложными формальными процессами и облегченными методами быстрой разработки привел к появлению методологии разработки под названием agile («проворный», «быстрый», «живой»). Принципы данного подхода сформулированы в Agile Manifesto (www.agilemanifesto.org), который был написан в феврале 2001 года семнадцатью представителями ряда «нетрадиционных» направлений в программировании, включая XP [1], Feature Driven Development, Crystal, Adaptive Software Development, SCRUM.

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

• Модульность. Процесс разработки разбивается на отдельные задачи, которые в совокупности позволяют преобразовать концепцию системы в реализацию. Задача — единица работы, имеющая определенную цель.
• Итеративность. Процесс разработки разбивается на короткие по времени циклы. В ходе каждой итерации выполняется некоторое множество задач, итерации завершаются в течение нескольких недель. Итеративность отвечает тем реалиям разработки, что в системе невозможно сразу удовлетворить все требования заказчика, приходится постоянно вносить изменения, чтобы устранить ошибки и точнее следовать поставленным целям. Поэтому итеративность подразумевает непрерывное взаимодействие с заказчиком.
• Ограниченность во времени. Для каждой итерации задаются жесткие ограничения по времени, и в соответствии с этим составляется календарный план проекта.
• Экономичность. В процесс разработки включается минимальное число задач, необходимых, чтобы достичь поставленной цели и снизить риски проекта.
• Адаптивность. В ходе разработки могут возникнуть новые риски, не учтенные при планировании проекта, и может оказаться так, что ранее определенные задачи не позволяют реализовать проект. В этом случае список задач, составляющих процесс, может быть изменен.
• Постепенность. Проект разбивается на части, которые могут разрабатываться параллельно, в разное время и с разной скоростью. Модульное тестирование для разных частей проекта проводится независимо, по его завершении часть интегрируется в систему.
• Ориентация на людей. Для реализации каждой части проекта формируются небольшие группы разработчиков, что позволяет им не чувствовать себя изолированно в большом коллективе проекта.
• Коллаборативность. Стимулируется постоянное сотрудничество между участниками проекта. Это необходимо для того, чтобы эффективно интегрировать разные компоненты системы при параллельной работе.
• Взаимодополняемость. Некоторые задачи, будучи реализованы в совокупности, дают лучший результат по сравнению с реализацией изолированно друг от друга. Определенные задачи можно использовать для оценки и улучшения результатов ранее выполненных задач.

Литература

1. К. Бек, Экстремальное программирование. // Открытые системы, 2000, № 1-2.
2. R. Miller, The Dynamics of Agile Software Processes. Borland Development Network, February 2003.

Основные вопросы проектирования

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

Выбор соответствующих технологий Выбор показателей качества Решение о путях реализации сквозной функциональности Более подробное описание процесса проектирования приводится в главе 4, « Методика построения архитектуры и дизайна ».

Определение типа приложения

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

В данном руководстве рассматриваются следующие основные типы приложений: Приложения для мобильных устройств. Насыщенные клиентские приложения для выполнения преимущественно на клиентских ПК. Насыщенные клиентские приложения для развертывания из Интернета с поддержкой насыщенных UI и мультимедийных сценариев.

BPM Часть 4. BPMS, Бизнес-требования и Техническое Задание

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

Офисные бизнес-приложения (Office Business Applications, OBAs), интегрирующие технологии Microsoft Office и Microsoft Server. Бизнес-приложения SharePoint (SharePoint Line of Business, LOB), обеспечивающие доступ к бизнес-данным и функциональным возможностям через портал. Более подробно архетипы приложений рассматриваются в главе 20, « Выбор типа приложения ».

Выбор стратегии развертывания

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

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

Выбор соответствующих технологий

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

Как писать требования так, чтобы команда хотела их читать / Александр Войтехович / ISsoft

Выбор показателей качества

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

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

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

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

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

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

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

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

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

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

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

Кэширование . Определите, что должно кэшироваться и где для улучшения производительности и сокращения времени отклика приложения. При проектировании кэширования не забудьте учесть особенности Веб-фермы и фермы приложений. Более подробно о сквозной функциональности рассказывает глава 17, « Сквозная функциональность ».

Источник: studfile.net

Процесс определения требований для SOA-проектов: Часть 2. Бизнес-требования для ваших первых SOA-сервисов

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

Кунал Миттал, директор по IT,

SonyPictures Entertainment

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

Введение

В первой статье данной серии вы узнали о том, как определять технические требования для проекта SOA (Service-Oriented Architecture – сервис-ориентированная архитектура). Мы начали с обсуждения того, что надо определять раньше — технические требования или требования бизнеса. Хотя «правильного» ответа на этот вопрос нет, судя по моему опыту, часто, если не всегда, SOA-проекты возглавляются департаментами информационных технологий (ИТ), и обсуждения, как правило, начинаются с технологии. В предыдущей статье подробно рассматриваются различные типы технических требований и разнообразные возможные ловушки, которых нужно остерегаться при определении этих требований.

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

Эта статья охватывает процесс определения требований и построения первых нескольких сервисов в вашем SOA-проекте. В третьей и последней статье серии мы перейдем от рассмотрения этих нескольких сервисов к вопросам сбора, документирования и управления требованиями для внедрения SOA в корпоративном масштабе.

С чего начать?

В этой статье предполагается, что вы четко определились с технологией SOA. Вы определили начальный набор технических требований для вашей SOA и сейчас спрашиваете себя: «Какие сервисы SOA мне следует внедрить?» Различные ИТ-подразделения вашей организации могут говорить разные вещи: одни захотят внедрить технические сервисы, такие как сервис управления контентом, другие — сервисы, связанные с безопасностью (аутентификация/авторизация), или что-то еще. Однако ключевым в SOA-проекте является первоначальный набор бизнес-требований. Я не хочу вдаваться в полемику о том, с чего начать, я предполагаю, что вы начинаете с бизнес-сервисов. Давайте для начала рассмотрим способы определения требований для этих бизнес-сервисов.

Определение сервиса

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

Определение сервисов сверху вниз

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

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

Рисунок 1. Нисходящий подход

Определение сервисов снизу вверх

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

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

Рисунок 2. Восходящий подход

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

Сбор требований для одного сервиса

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

Типы требований

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

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

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

● Взаимодействие. Как сервис или приложение, которое вызывает сервис, взаимодействует с этим сервисом? Как сервис обрабатывает ошибки?

● Информация. Какие данные посылаются сервису и что он возвращает?

● Процесс. Каковы взаимоотношения между действиями и событиями в сервисе?

Процесс определения требований

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

Нужно четко понимать, что степень участия заказчиков со стороны бизнеса в вашем SOA-проекте является одним из главных факторов риска проекта. Вам нужно вовлечь менеджмент, показать им значение SOA и убедить их в том, что вы сделаете все «вовремя, быстрее и дешевле» (то, что их волнует).

С точки зрения процесса вам нужно получить от «поставщика» сервисов описание того, какая функциональность будет присутствовать в сервисе и какая отсутствовать. Сначала вы собираете различную информацию, описанную в предыдущей части статьи, используя любую методологию или инструментарий сбора требований: IBM® Rational® Unified Process и IBM Rational RequisitePro® или обычный текстовый документ по итогам импровизированного совещания по требованиям. На этом этапе я бы не рекомендовал слишком формализовать процесс. Идея в том, чтобы быстро реализовать несколько сервисов для демонстрации значимости вашего SOA-проекта. Однако вам все равно нужно как-то задокументировать эти требования.

Документирование требований для одного сервиса

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

Возможно, вам уже приходилось иметь дело со сценариями использования. Это превосходный способ определения требований для SOA-проекта. На рисунке 3 показан пример шаблона сценария использования, который вы можете использовать для документирования своих требований. В Rational RequisitePro и других средствах Rational имеется много других полезных шаблонов.

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

Рисунок 3. Шаблон сценария использования

Заключение

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

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

Источник: ecm-journal.ru

Жизненный цикл разработки ПО, фазы, процессы, модели.

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

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

Что вы узнаете:
Процесс жизненного цикла разработки ПО

Циклы разработки ПО

Фазы разработки ПО
1) Сбор и анализ требований
2) Дизайн
3) Программирование и внедрение
4) Тестирование
5) Установка
6) Поддержка
Модели жизненного цикла разработки ПО
1) Водопадная модель
2) V-образная
3) Прототипная модель
4) Спиральная
5) Итеративно -инкрементальная модель
6) Модель большого взрыва
7) Agile модель
Выводы
Рекомендации

Процесс жизненного цикла разработки ПО

Жизненный цикл разработки ПО это процесс который определяет различные этапы включенные в разработку ПО для поставки высококачественного продукта. Этапы SDLC включают все этапы жизненного цикла ПО, т.е. от зарождения до вывода продукта из работы.

Соблюдение рекомендаций SDLC ведет к систематической и дисциплинированной разработке программного обеспечения.

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

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

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

Циклы разработки ПО
Этапы SDLC представляют собой процесс разработки ПО.

Внизу представлена диаграмма описывающая основные этапы SDLC

Этапы SDLC
Ниже представлены основные этапы разработки:

• Сбор и анализ требований
• Дизайн
• Программирование
• Тестирование
• Установка
• Поддержка

#1) Сбор и анализ требований

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

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

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

Как только требования ясно представлены и поняты создается SRS (Software Requirement Specification) или Спецификация требований программного обеспечения. Данный документ должен быть тщательно изучен и правильно понят разработчиками и самим клиентом.

#2) Дизайн
На данном этапе, требования зафиксированные в Спецификации используются как исходные данные для создания архитектуры, которая используется при разработке приложения.

#3) Программирование
Программирование начинается как только разработчик получил документ с архитектурой продукта. Дизайн ПО интерпретируется в код. На данном этапе создаются все компоненты ПО.

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

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

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

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

#4) Поддержка
После ввода ПО в эксплуатацию, осуществляется поддержка продукта т.е. если возникает какая-либо проблема, которую необходимо исправить, или необходимо внести какие-либо улучшения, разработчики займутся этим.

Модели жизненного цикла разработки ПО

Модели жизненного цикла разработки ПО это описательное представление процесса разработки ПО. SDLC (Software Development Life Cycle, SDLC) могут иметь различные подходы, но основные этапы и действия остаются одинаковыми для всех моделей.

#1) Водопадная модель

Водопадная модель первая модель из ряда SDLC. Ее также называют линейной последовательной моделью, каскадная моделью.

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

• Первое, сбор и анализ требований завершен. Когда требования утверждены, далее может начинаться создание системного Дизайна или Архитектуры приложения. Здесь создается SRS (Software Requirement Specification) или Спецификация требований программного обеспечения. То есть Спецификация является итогом сбора требований, и служит основой для создания системного Дизайна или Архитектуры приложения.
• На этапе системного Дизайна или Архитектуры приложения, создаются документы которые служат основной для следующего этапа — Программирования.
• На этапе Программирования команда разработки пишет код, создает компоненты приложения. Результат работы команды разработки служит для запуска следующего этапа — Тестирование.
• На этапе тестирования, полученный продукт тщательно тестируется на предмет наличия ошибок. Баги заносятся в системе баг-трекинга (Система отслеживания ошибок) и проходят повторное тестирование после исправления. Фиксирование багов, повторное тестирование, регрессионное тестирование проводится до тех пор, пока ПО не переходит в рабочее состояние, пока не начинает корректно работать.
• На этапе Установки, разработанное приложение запускается в эксплуатацию после одобрения заказчиком.
• Все проблемы возникающие в процессе эксплуатации решаются командой разработки в рамках Поддержки.

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

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

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

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

#2) V-образная модель

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

Этап Верификации:

1. Сбор и анализ требований
   На данном этапе, собирается вся необходимая информация собирается и анализируется. Верификация заключается в проверке, обзоре требований.

1) Юнит — тестирование
Юнит — тестирование (Модульное тестирование) выполняется с использованием сценариев модульного тестирования, которые разработаны и выполняются на этапе низкоуровневого проектирования. Модульное тестирование выполняет сам разработчик. Он выполняется на отдельных компонентах, что приводит к раннему обнаружению дефектов.

2) Интеграционное тестирование
Интеграционное тестирование выполняется используя интеграционные тест кейсы на этапе разработки высокоуровневого дизайна. Интеграционное тестирование — это тестирование интегрированных модулей. Производится тестировщиками.

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

4) Приемочное тестирование
Приемочное тестирование связано с этапом Анализом требований и производится в рабочей среде заказчика.

Преимущества V-образной модели

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

Недостатки V-образной модели

• V-образная не подходит проектов в разработка (текущих проектов)
• Изменение требований на более позднем этапе приведут к повышению издержек.

#3) Прототипная модель разработки ПО

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

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

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

Как только завершили процесс сбора требований, в скором времени создается первая версия прототипа которая предоставляется клиенту для оценки (билд).

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

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

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

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

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

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

Спиральная модель включает итеративный и прототипный подходы.
Этапы спиральной модели следуют по итерациям. Петли данной модели представляют этапы SDLC (Software Development Life Cycle, Модели жизненного цикла разработки ПО) т.е. ключевой момент — сбор и анализ требований за которым следуют Планирование, Анализ рисков, разработка и оценка качества. Следующая петля это Разработка Дизайна и следующими за ней Разработка и тестирование.

У спиральной модели есть четыре этапа:
Планирование
Анализ рисков
Разработка
Оценка

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

Анализ рисков:
На этом этапе выбирается лучшее решение с учетом имеющихся рисков и проводится анализ путем создания прототипа.

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

Разработка:
Как только завершен анализ рисков, следует программирование и тестирование.

Оценка:
Клиент оценивает разработанную систему и планируется следующая итерация.

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

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

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

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

#5) Итеративно инкрементальная модель

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

Пример: Определен и разработан функционал который будет реализован в рамках итерации. Каждая интеграция проходит этапы Анализ требований, Дизайн, Программирование и Тестирование. Детализированный план не требуется в итерации.

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

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

Этапы итеративно инкрементной модели:

• Начальный этап
• Этап разработки
• Этап Создания
• Переходный этап

Начальный этап
Начальный этап включает в себя сбор требований и определение рамок проекта

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

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

Переходный этап
На переходном этапе продукт устанавливается в рабочем окружении клиента.

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

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

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

• Полные требования и понимание продукта необходимы для декомпозиции и разработки.

#6) Модель большого взрыва

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

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

Преимущества модели Большого взрыва

• Очень простая модель.
• Не требуется планирования и определенного процесса.
• Команде разработки предоставлена свобода по созданию продукта как -будто для себя.
• Так как продукт декомпозирован на мелкие задачи им легко управлять

Недостатки модели Большого взрыва

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

#7) Agile модель
Agile модель это комбинация итеративной и инкрементальной модели разработки. Данная модель скорее сосредоточена на гибкости во время создания продукта, чем на требованиях.

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

В Agile итерации называются спринтами. Каждый спринт длится 2-4 недели. В конце каждого спринта владелец продукта проверяет продукт и после его подтверждения, продукт загружается для клиентов.

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

Преимущества модели Agile

• Это позволяет более гибко адаптироваться к изменениям.
• Новую функцию можно легко добавить.
• Удовлетворенность клиентов, отзывы и предложения принимаются во внимание на каждом этапе.

Недостатки модели Agile

• Отсутствие документации.
• Для создания продукта нужны опытные и высококвалифицированные ресурсы.
• Если клиент не понимает, каким именно он хочет видеть продукт, проект провалится.

#Выводы.

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

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

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

Водопадная модель является базовой моделью, и все остальные модели SDLC основаны только на ней.

Надеюсь, вы получили новые знания о SDLC.

Источник: egorkv.com

Основы подготовки приложений к развертыванию (Application packaging)

«Application packaging» устоявшийся термин для названия IT сервиса в сфере поддержки конечных пользователей (EUS) во всем мире, но, практически не известный в России. Поэтому в нашей статье опишем лучшие практики, которые скрываются за данным сервисом и расскажем о том, как он может помочь снизить общую стоимость владения (TCO) программным обеспечением и, в конечном счете, уменьшить стоимость поддержки рабочих мест пользователей.

Стратегия и подходы. Снижение TCO.

Стоимость владения программным обеспечением (ПО) занимает существенную долю IT-бюджета любой современной компании, что обуславливает актуальность управления (подходами, стратегией и т.д.) как бюджетом, так и программами с целью снижения стоимости поддержки рабочих мест пользователей. Один из таких проверенных временем подходов – это Application packaging (рус. авторский перевод «Подготовка приложений к развертыванию»).

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

• Возможность установки в тихом режиме (silent) для того, чтобы не отвлекать пользователя от работы.
• Отключение обновлений для минимизации траффика и контроля используемых версий программ (и минимизации количества разнородных версий, что удорожает обслуживание программ)
• Установка строго без перезагрузок и выключений компьютера, чтобы не прерывать работу конечных пользователей, даже в самых сложных ситуациях, когда того требует разработчики программного обеспечения.
• Автоматическое удаление предыдущей версии программного обеспечения на уровне пакета для минимизации усилий по развертыванию.
• И сотни других практик….

ROI (Return of investments)

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

Так, например, в статье JUKKA KOULETSIS: The Basics of Application Packaging приводится опыт компании Dell, где утверждается, что использование практик (сервиса) по подготовке программ к развертыванию позволяет единожды вложившись в разработку и тестирование пакета, сократить стоимость их поддержки:

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

В производственном секторе мы работаем с двумя компаниями (европейскими подразделениями), изготавливающими шины. Это мировые лидеры (из ТОП-10) с более 10 тыс. рабочих станций. Только за счет использования практик application packaging нам удалось довести состав команды развертывания до 1 человека (без учета бекапов). Другими словами, мы смогли компенсировать 80% затрат на подготовку приложений уже на этапе развертывания, при этом на начальном этапе количество инцидентов, связанных с приложениями, удалось сократить на 45% соответственно:

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

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

Технологии и решения

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

Самой известной технологией является Microsoft Windows Installer — подсистема Microsoft Windows, обеспечивающая установку программ в специальном формате .msi. В отличие от неконтролируемых и неуправляемых setup.exe технология предоставляет ряд преимуществ, которые делают ее крайне популярной:

• процесс установки можно контролировать стандартными политиками ОС Windows;
• информация об устанавливаемых программах содержится в структурированном виде (база данных) и cab архивах, что обеспечивает прозрачность (в том числе для антивирусов);
• возможно самовосстановление при повреждении отдельных ресурсов, что сокращает количество инцидентов;
• возможность принудительного восстановления, что сокращает время на восстановление работоспособности приложения, в случае потери целостности;
• возможность преактивного выявления конфликтов между приложениями и их устранение,
• и т.д.

Поэтому в определённых ситуациях становиться выгодной конвертация установочных файлов формата Exe (Setup.exe) в формат Windows Installer. Для этих целей мы используем решение AdminStudio Repackager от Flexera Software.

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

Уже на сегодняшний день половина наших крупных европейских заказчиков используют AppV как основную технологию, а Windows Installer применяют там, где не применим AppV. Последний особенно выгоден, где повсеместно используются терминальные среды. Для них Application packaging за счет управления конфликтами (проактивного поиска и устранения) и проактивного анализа возможности использования на терминальных средах позволяет не только получить все плюсы, описанные выше, но и более рационально использовать физические сервера, сократить количество ребилдов серверов и общее количество инцидентов и проблем, то есть снизить стоимость владения до 25% процентов. Для управления конфликтами (conflict management) мы используем свои разработки, а также решение Application Manager от Flexera Software.

Более того, использование сервисов по подготовке приложений к развертыванию позволяет существенно снизить риски и стоимость миграций в новые среды (например, из десктопных решений на терминальные или на новую ОС). Так, сейчас мы активно работаем над миграцией наших некоторых клиентов на Windows 10. И для тех заказчиков, где уже используется Application packaging – мы делаем эту работу за считанные недели/месяцы в зависимости от размера компании. Там же, где Application packaging еще не используется, время миграции – это самый лучший период для внедрения сервиса, попутно проведя оптимизацию состава программного обеспечения, что по факту может сэкономить в разы только бюджет на миграцию, не говоря уже о дальнейшей стоимости поддержки. О том, какие программы используются для рационализации, чуть ниже в этом материале.

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

• Colibri tracker – решение позволяет нам управлять процессом подготовки приложений к развертыванию, а также поддерживать проекты по миграции операционных систем, приложений и т.д. Помимо трекинга задач (программ/пакетов) по жизненному циклу, в данной утилите реализована конвейерная автоматизация и интеграция с ITSM системами, системами развертывания (SCCM / Altiris и т.д.) и другим ПО (в том числе приведенным в данной статье), которая позволяет нам сократить временные издержи на 45% и предложить оптимальные цены для наших заказчиков за счет слаженности, гибкости, синергии в управлении работами: Colibri предоставляется нами также как SaaS решение.
• Inventory Intelligence portal. Чтобы что-то сделать лучше, необходимо сперва понять «как есть» сейчас и подумать «где и что» можно рационализировать. Данная программа использует результаты работы утилит для инвентаризации (от Microsoft, Lakeside) и помогает проводить «интеллектуальный» анализ:
• исключить неиспользуемый и забытый софт;
• исключить программы с одинаковым назначением, сделав выбор в пользу наиболее оптимальных;
• понять, где можно использовать меньшее количество лицензий, чем было закуплено ранее или планировалось закупить.

Совокупность решений сторонних вендоров и наших решений позволяет нам оказывать сервисы на высоком уровне даже для зрелых IT-инфраструктур за адекватную стоимость.

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

Источник: habr.com

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

Вадим

Noveo Test Engineer

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

Цели этого поста заключаются в следующем:

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

Требования

Начнем с требований как таковых:

• Что они из себя представляют?
• Какие виды требований выделяются?
• Как они согласуются?
• Какие источники требований можно выделить?

Определение требования

Прежде чем погрузиться в теорию разработки требований к ПО, попробуйте, основываясь на своих знаниях и опыте, ответить на вопрос: как вы определяете термин «требование»?

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

Требования к ПО — это спецификация того, что должно быть реализовано. В них описано поведение системы, свойства системы или ее атрибуты. Они могут служить ограничениями в процессе разработки системы (Ian Sommerville и Pete Sawyer, 1997).

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

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

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

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

Термин «требование» охватывает довольно широкую предметную область. Поэтому возникает вопрос типизации и классификации требований.

Уровни и типы требований

Требования к ПО состоят из трех уровней:

1. Бизнес-требования.
2. Пользовательские требования.
3. Функциональные требования.

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

Бизнес-требования BRQ

Бизнес-требование (business requirements) — высокоуровневая бизнес-цель организации или заказчиков системы.

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

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

Если кратко, документ содержит определение следующих понятий:

• Бизнес-возможности, бизнес-проблемы — факты и события, формирующие бизнес-цели, то есть грубо — причины инициации проекта.
• Бизнес-цели — цели, которые должны быть решены разработкой и вводом в эксплуатацию системы. Являются критериями успеха проекта.
• Концепция продукта (Vision) — сжато описывает конечный продукт, который достигнет заданных бизнес-целей.
• Границы проекта (scope) — показывают, на какую часть конечной концепции продукта будет направлен текущий проект или итерация.

Примеры бизнес-требований:

Сократить время обработки заказа на 50% (цель) — система должна предоставить интерфейс, упрощающий создание заказа (концепция).

Увеличить клиентскую конверсию до 35% (цель) — в системе должны быть представлены механизмы побуждения клиента к заказу (концепция).

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

Источники бизнес-требований (где искать?):

• Внутренняя документация компании (положения, инструкции, приказы).
• Документация по предметной области (профильные литература и статьи, исследования).
• Нормативная документация (законы и иные правовые акты, государственные стандарты).
• Продукты конкурентов.

Стейкхолдеры (у кого спрашивать?):

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

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

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

Пользовательские требования URQ

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

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

Пользовательские требования также часто именуются фичами.

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

Исходя из вышеописанных определений, пользовательские требования содержат:

• Цели и задачи пользователей.
• Сценарии использования — способ решения задачи пользователей.
• Как следствие, описание самих пользователей системы:
• пользовательские роли,
• уровни доступа.

В конечном итоге пользовательские требования формируют «Документ пользовательских требований». Пользовательские требования могут быть представлены в виде:

• текстового описания,
• вариантов использования, сценариев использования (Use Case),
• пользовательских историй (User Story),
• диаграммы вариантов использования.

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

Пользователь должен иметь возможность + {тезис}.

Пример пользовательского требования:

Пользователь должен иметь возможность добавить объект в избранное (функциональность).

Источники пользовательских требований требований (где искать?):

• Анализ и декомпозиция бизнес-требований.
• Описание бизнес-процессов.
• Артефакты бизнес-процессов:
• документы входные/выходные,
• стандарты,
• регламенты,
• обрабатываемые данные,
• иная информация, используемая и/или производимая в бизнес-процессе.
• Отраслевые стандарты.
• Реализованные проекты, проекты конкурентов.

Стейкхолдеры (у кого спрашивать?):

• Бизнес-аналитик, системный-аналитик.
• Конечные пользователи — люди, взаимодействующие с системой напрямую.
• Косвенные пользователи — люди, использующие результаты работы системы, не взаимодействуя с ней напрямую.
• Представители пользователей.
• Менеджер проекта.
• Руководитель структурного подразделения заказчика.

Этот уровень требований напрямую входит в круг обязанностей QA-инженера. В задачи QA на этом уровне входит:

• Определение соответствия описания требований критериям качества.
• Анализ требований для проработки сценариев тестирования.
• При достаточном уровне компетенций в предметной области:
• определение соответствия требований устоявшимся отраслевым стандартам (например: системе не достаёт фичи, которая в рамках предметной области системы является обязательной);
• определение соответствия требований с утвержденными бизнес-требованиями. Ответ на вопрос: «Решает ли пользовательское требование бизнес-цели проекта и задачи пользователей?«.

Функциональные требования FRQ

Функциональные требования (functional requirements) — описание требуемого поведения системы в определенных условиях.

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

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

Пример функциональных требований:

Пользователь должен иметь возможность добавить объект в избранное (URQ):

FRQ 1 — Добавить в избранное.

FRQ 2 — Удалить из избранного.

FRQ 3 — Редактирование дополнительных атрибутов.

FRQ 4 — Обращение к объекту из меню избранного.

Источники требований (где искать?):

• Анализ пользовательских требований.
• Таски.
• Прототипы интерфейса (мокапы).
• Отраслевые стандарты.
• Внешние системы и документация к ним (интеграции).

Стейкхолдеры (у кого спрашивать?):

• Бизнес-Аналитик.
• Системный аналитик.
• Архитектор.
• Менеджер проекта.
• Разработчики.

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

Нефункциональное требование (non-functional requirements) — описание свойства или особенности, которым должна обладать система, или ограничение, которое должна соблюдать система.

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

1. Выявляются и формулируются на всех уровнях иерархии требований.
2. Напрямую или косвенно влияют на формирование каждого уровня требований.

Совет: Чаще всего нефункциональные требования отвечают на вопрос «Как? Каким образом?».

Пример нефункциональных требований, которые являются основной идеей проекта: Тик Ток.

С точки зрения разработки функциональный скоуп проекта не является уникальным:

• смотреть контент,
• предлагать ротацию контента на основе алгоритмов,
• создавать контент.

Все эти фичи так или иначе были представлены в других проектах. Ключом успеха проекта в данном случае является его UI/UX. А UI/UX сам по себе не отвечает за функции системы, а отвечает за то, каким образом будут реализованы эти функции.

SRS

В конечном итоге все требования консолидируются в одном документе «Спецификации требований к системе». Выше вы можете видеть структуру документа SRS. Ни в коем случае нельзя воспринимать её как жесткий стандарт (хотя таковой имеется: ISO/IEC/IEEE 29148:2011). Я предлагаю вам использовать эту структуру как чек-лист для определения полноты описания системы. Стоит отметить, что внутренние стандарты документирования и полноты требований меняются от проекта к проекту, но набор типов требований всегда будет идентичен. Кто-то опускает бизнес-требования, для кого-то пользовательские требования тождественны функциональным. В конечном итоге все требования — лишь абстракция, и каждая команда подбирает под себя удовлетворительный уровень детализации этой абстракции.

Выявление требований

Выявление требований — итеративный процесс, состоящий из следующих этапов:

1. Подготовка к выявлению.
2. Выявление.
3. Утверждение результатов.

Подготовка к выявлению требований

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

1. Что необходимо выяснить? — Анализируем имеющуюся информацию о системе:

а. Анализ текущего описания требований к системе.

b. Анализ текущей реализации системы.

c. Выявление недостающих и/или недостаточно описанных требований.

2. У кого? Где? — Определить источник требований:

а. Собрать список доступных источников, таких как:.

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

ii. Артефакты бизнес-процессов и/или текущей реализации системы.

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

3. Каким образом? — Выбрать оптимальный метод выявления требований.

Выявление требований. Интервью

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

Подготовка к интервью

Подготовка к интервью состоит из следующих этапов:

1. Собрать информацию о собеседнике(ах):

а. Роль в проекте?

b. За какие вопросы ответственен?

2. Подготовить вопросы:

a. Сформулировать проблематику интервью.

b. Сформулировать вопросы.

c. Подготовить дополнительные вопросы.

3. Определить тайминг встречи.

a. Нужно стараться уложиться в один час. Чаще всего человек начинает терять концентрацию после 40 минут непрерывной беседы.

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

c. Если вы не успеете задать все вопросы в рамках одной встречи, назначьте несколько встреч.

4. Согласовать календарь встреч.

a. Если предполагается несколько встреч — то не обходимо составить график встреч.

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

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

Протокол интервью

Проект:{}

Дата проведения:{}

Интервьюер: {Кто проводит интервью}

Интервьюируемый:{Кому задаём вопросы}

Проблематика:{Тема интервью}

Вопрос № 1:

Тайминг вопроса:

Текст вопроса:

Таймкод:

Ответы на вопрос:

Стейкхолдер 1 —

Стейкхолдер 2 —

Проведение Интервью

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

1. Всегда ведем запись встречи.

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

b. Включаем запись после согласия собеседника.

2. Small talk для разрядки.

a. Как настроение?

b. Как погода?

c. И т.д. и т.п.

d. Но не затягиваем, пара вопросов из вежливости, не более.

3. Начинаем с объявления проблематики.

4. Стараемся следовать плану встречи. Вопросы задаём последовательно.

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

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

7. В конце обсуждения не лишним будет подтвердить позицию собеседника закрытым типом вопроса.

a. Например: Я правильно вас понял, что необходимо реализовать функционал следующим образом {Тезис}?

Обработка результатов Интервью

После проведения интервью необходимо письменно зафиксировать полученную информацию. Рекомендую делать это сразу после интервью. Итак:

1. Заполняем протокол встречи.

a. Читать краткий протокол встречи намного проще, чем смотреть часовую запись в поисках ответов.

2. Направляем участникам встречи результаты в формате «Вопрос — Зафиксированное решение».

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

Плюсы и минусы метода

Плюсы метода:

• Наиболее эффективный способ метод сбора требований.
• Меньшая вероятность недопонимания между собеседниками.
• Большая вероятность выявления «скрытых» требований.

Минусы метода:

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

Выявление требований. Анкетирование

Метод анкетирования подразумевает создание анкеты (списка вопросов) и её рассылку большому количеству опрашиваемых.

Подготовка

Подготовка к анкетированию состоит из следующих этапов:

1. Собрать контакты опрашиваемых стейкхолдеров.

2. Подтвердить готовность стейкхолдеров участвовать.

3. Подготовить анкету:

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

b. Задавать можно как открытые, так и закрытые вопросы.

c. Но лично я рекомендую предоставлять опрашиваемым варианты ответа даже в формате открытого вопроса. То есть обозначаем проблематику, предлагаем варианты решения, а также оставляем за опрашиваемым возможность раскрыть свою позицию. По сути аналог варианта «Другое» в опроснике.

Проведение

1. Рассылаем анкету опрашиваемым.
2. Контролируем сроки опроса (должен быть внутренний дедлайн).
3. Ответы, по мере поступления, консолидируем в одном документе (каналы связи с опрашиваемыми могут быть разными, но место хранения требований всегда должно быть одно).

Обработка результатов

1. Анализируем ответы.
2. Фиксируем требования.
3. Утверждаем требования с ответственными лицами.

Плюсы и минусы метода

Плюсы:

• Большой охват опрашиваемых.
• Сравнительно небольшие временные затраты.
• Возможность повторного использования анкеты (бриф на стандартизированный проект).

Минусы:

• Не подходит для выявления «неявных» требований.
• Невозможно заранее учесть все необходимые вопросы.

Выявление требований. Мозговой штурм

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

Подготовка

1. Формулируем проблематику:

а. Необходима краткая и емкая формулировка, которая оставит поле для размышления экспертов.

b. Проблематика озвучивается экспертам заранее, чтобы у них было время «на подумать».

2. Подготавливаем дополнительные материалы для отработки идей — например, макеты системы.

3. Формируем группу экспертов.

4. Согласовываем дату и время.

Проведение

1. Ведем запись-протокол. Уведомляем участников о том, что ведется запись.

2. Озвучиваем регламент встречи:

a. Тема,

b. Тайминги,

c. Правила.

3. Эксперты озвучивают идеи по очереди.

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

5. Каждая идея фиксируется и обсуждается.

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

7. Коллективное комбинирование собранных идей.

Обработка результатов

1. Анализируем идеи.
2. Формализуем и описываем (то есть готовим развернутое описание).
3. Утверждаем идеи с ответственными.

Плюсы и минусы метода

Плюсы:

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

Минусы:

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

Другие методы выявления требований

• Анализ документации — изучение и анализ существующей документации, которая напрямую или косвенно касается разрабатываемой системы.
• Анализ системных интерфейсов, API и базы данных — анализ систем, которые будут взаимодействовать с разрабатываемой системой.
• Анализ пользовательского интерфейса — анализ интерфейсов, функционально похожих (или идентичных) на разрабатываемую систему (отраслевые стандарты UI/UX). Также к этому относится анализ интерфейсов систем, входящих в IT-экосистему заказчика.
• Моделирование процессов, поведения системы и пользователей — моделирование процессов и схем данных помогает структурировать и упорядочивать информацию о проекте.
• Повторное использование требований — многие элементы систем имеют стандарты исполнения. Например: регистрация — авторизация пользователей.
• Вовлечение представителя заказчика в команду разработки — вовлечение заказчика в работу над проектом является одним из постулатов Agile. В целом наличие представителя заказчика в команде разработки экономит уйму времени на коммуникации.
• Презентации, демо и т.п. — представление требований/реализации системы заказчику. Данный способ помогает уточнить требования, а также выявить скрытые и/или избыточные требования. Пример: демонстрация мокапов будущей системы пользователям.
• Работа в «Поле» (наблюдение) — наблюдение за деятельностью и процессами будущих пользователей.
• Обучение — процесс, в котором заказчик или любой другой человек из организации заказчика, знающий процесс, обучает аналитика по принципу «учитель — ученик».

Очевидный факт:

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

Материалы для самостоятельного изучения

Блоки знаний:

• Бизнес-анализ — раздел знаний, отвечающий за описание и формализацию бизнес-процессов. Прежде чем интерпретировать бизнес-процессы в виде ПО, необходимо их «правильно» описать и формализовать.
• Моделирование бизнес-процессов — изучение различных нотаций описания бизнес-процессов. Неразрывно связан с бизнес-анализом.
• Системный-анализ — раздел знаний, отвечающий за анализ процессов непосредственно в самом ПО.
• Моделирование систем — изучение нотаций описания систем ПО. Неразрывно связан с системным анализом.
• Документирование требований — изучение различных сред документирования информации о проекте и системе.
• Управление требованиями (согласование, управление изменениями, трассировка требований) — отдельный процесс в системе знаний об анализе в ИТ. Является одним из самых сложных процессов на долгосрочных проектах с большим количеством итераций.
• Прототипирование — изучение различных инструментов для моделирования интерфейсов и архитектуры ПО. Например: Figma для верстки макетов интерфейсов.

Книги:

• Вигерс, Карл: Разработка требований к программному обеспечению. 3-е издание, дополненное / Карл Вигерс, Джой Битти. — Санкт-Петербург : БХВ-Петербург, 2019. — 736 с.
• Ильяхов М., Сарычева Л. Пиши, сокращай. Как создавать сильный текст — 2017.
• Гэртнер, Маркус: ATDD — разработка программного обеспечения через приемочные тесты. — ДМК-Пресс, 2013. — ISBN 978-5-457-42706-8.
• Gojko Adzic, David Evans — Fifty Quick Ideas to Improve Your User Stories — 2014.
• Майкл Мескон, Майкл Альберт, Франклин Хедоури — Основы менеджмента

• Хоп, Грегор Шаблоны интеграции корпоративных приложений (Signature Series) / Грегор Хоп, Бобби Вульф. — Москва : Вильямс, 2019. — 672 с.

• Кон, Майк Пользовательские истории. Гибкая разработка программного обеспечения / Майк Кон. — Москва : Вильямс, 2018. — 256 с.

• Паттон, Джефф Пользовательские истории. Искусство гибкой разработки ПО / Джефф Паттон — Санкт-Петербург : Питер, 2019. — 288 с.

• Cockburn, Alistair Writing Effective Use Cases / Alistair Cockburn. — Addison-Wesley, 2001.

• USE-CASE 2.0

• Фаулер, Мартин UML. Основы. Краткое руководство по стандартному языку объектного моделирования / Мартин Фаулер. — Москва : Символ-Плюс, 2018. — 192 с.

• Гойко, Аджич Impact Mapping. Как повысить эффективность программных продуктов и проектов по их разработке / Аджич Гойко. — Москва : Альпина Паблишер, 2017. — 86 с.

• Коберн, Алистер Быстрая разработка программного обеспечения/ Алистер Коберн. — Москва: Лори, 2002. — 336 с.

• Корнипаев, Илья Требования для программного обеспечения: рекомендации по сбору и документированию / Илья Корнипаев. — Книга по требованию, 2013. — 118 с. Книга

• Ми, Роберт Шаблоны корпоративных приложений / Роберт Ми, Мартин Фаулер. — Москва : Вильямс, 2018. — 544 с.

• Мартин, Роберт Чистая архитектура. Искусство разработки программного обеспечения / Роберт Мартин. — Санкт-Петербург : Питер, 2018. — 352 с.

• BABOK 3.0

• SWEBOK 3.0

1.

Разработка стратегии
развертывания
приложений

2.

Continuous deployment
Непрерывное развертывание (CD , Continuous deployment) – практика
разработки
программного
обеспечения,
направленная
на
автоматизацию поставки от среды разработки в промышленную среду.
полную

3.

Стратегии развертывания
Rolling (постепенный, «накатываемый» деплой)
Recreate (повторное создание)
Blue/Green (сине-зеленые развертывания)
Canary (канареечные развертывания)
Dark (скрытые) или А/В-развертывания

4.

Rolling
Это стандартная стратегия развертывания в Kubernetes. Она постепенно, один
за другим, заменяет pod’ы со старой версией приложения на pod’ы с новой
версией — без простоя кластера.
Kubernetes дожидается готовности новых pod’ов к работе (проверяя их с
помощью readiness-тестов), прежде чем приступить к сворачиванию старых.
Если возникает проблема, подобное накатываемое обновление можно
прервать, не останавливая всего кластера.

5.

6.

Recreate
В этом простейшем типе развертывания старые pod’ы убиваются все разом и
заменяются новыми.

7.

8.

Blue/Green
Стратегия сине-зеленого развертывания (иногда ее ещё называют red/black,
т.е. красно-чёрной) предусматривает одновременное развертывание старой
(зеленой) и новой (синей) версий приложения. После размещения обеих
версий обычные пользователи получают доступ к зеленой, в то время как
синяя доступна для QA-команды для автоматизации тестов через отдельный
сервис или прямой проброс портов:

9.

10.

Canary
Канареечные выкаты похожи на сине-зеленые, но лучше управляются и используют
прогрессивный поэтапный подход. К этому типу относятся несколько различных
стратегий, включая «скрытые» запуски и А/В-тестирование.
Эта
стратегия
применяется,
когда
необходимо
испытать
некую
новую
функциональность, как правило, в бэкенде приложения. Суть подхода в том, чтобы
создать два практически одинаковых сервера: один обслуживает почти всех
пользователей, а другой, с новыми функциями, обслуживает лишь небольшую
подгруппу пользователей, после чего результаты их работы сравниваются. Если все
проходит
без
инфраструктуру.
ошибок,
новая
версия
постепенно
выкатывается
на
всю

11.

Canary
Хотя данную стратегию можно реализовать исключительно средствами
Kubernetes, заменяя старые pod’ы на новые, гораздо удобнее и проще
использовать service mesh вроде Istio.
Например, у вас может быть два различных манифеста в Git: обычный с
тегом 0.1.0 и «канареечный» с тегом 0.2.0. Изменяя веса в манифесте
виртуального шлюза Istio, можно управлять распределением трафика между
этими двумя deployment’ами:

12.

13.

Dark или А/В-развертывания
Скрытое развертывание — еще одна вариация канареечной стратегии. Разница
между скрытым и канареечным развертыванием состоит в том, что скрытые
развертывания имеют дело с фронтендом, а не с бэкендом, как канареечные.
Другое название этих развертываний — А/В-тестирование. Вместо того, чтобы
открыть доступ к новой функции всем пользователям, ее предлагают лишь
ограниченной их части. Обычно эти пользователи не знают, что выступают
тестерами-первопроходцами (отсюда и термин «скрытое развертывание»).
С помощью переключателей функциональности (feature toggles) и других
инструментов можно следить за тем, как пользователи взаимодействуют с новой
функцией, увлекает ли она их или они считают новый пользовательский
интерфейс запутанным, и другими типами метрик.

14.

15.

Целевые инструменты CD

16.

17.

Nexus
Nexus — это централизованное хранилище. Это хранилище делится на два логических
элемента.
Репозиторий разработки Nexus — хранилище содержит системное ПО; различные
библиотеки, использующиеся как зависимости; результаты ночных сборок; сборок из
feature веток. Также этот репозиторий зеркалит различные общедоступные в Интернет
репозитории, которые необходимы для процесса разработки. В общих словах этот
репозиторий содержит все, что нужно для процесса Continuous Integration. К этому
хранилищу применяются обычные требования по отказоустойчивости и по сохранности
данных. Сборки в этом репозитории хранятся не более одного месяца.

18.

Nexus
Nexus — это хранилище инсталляционных пакетов (дистрибутивов) передаваемых
в Банк. Этот Nexus служит гарантией того, что тот же самый дистрибутив,
собранный один раз под одной версией, разворачивался и тестировался на всех
этапах
тестирования.
То
есть
это
хранилище
служит
для
обеспечения
непрерывной связи двух процессов — Continuous Delivery и Continuous Deployment.
К этому хранилищу применяются повышенные требования по отказоустойчивости
и по сохранности данных. То, как долго хранятся дистрибутивы в этом,
репозитории определяется требованиями.

19.

Jenkins
Jenkins — это проект с открытым исходным кодом, написанный на Java, созданный
решать огромное число задач по оркестрации различных процессов. В нашем
случае Jenkins выбран как целевое решение для оркестрации процессов
развертывания как на средах тестирования в СБТ, так и на средах приемо-
сдаточых испытаний и промышленных средах.
Не предполагается, что Jenkins будет оркестрировать весь процесс от среды
разработки
до
промышленной
среды.
С
помощью
Pipeline
plugin
будут
оркестрированы отдельные части процесса, например, развертывание ОРД в
среды СТ и в среды ИФТ – это два разных Pipeline процесса в рамках одной
проектной области в сервисе CD Jenkins.

20.

Pipeline plugin
Pipeline plugin — решение, реализованное в виде плагина к Jenkins, позволяющее воплотить принцип
«процесс развертывания как код», то есть с помощью этого плагина сам процесс развертывания
представлен в виде Groovy кода. Pipeline plugin также предоставляет огромное число уже готовых
модулей (функций Groovy) для реализации различных задач, а также имеет подробную документацию по
каждому модулю — это обеспечит низкий порог вхождения, то есть не надо обучаться языку Groovy для
того, чтобы начать создавать несложные процессы развертывания.
Используя данный плагин для всех своих развертываний мы решаем несколько задач:
Версионирование сценария развертывания — версии Groovy кода процесса развертывания будут
храниться не в самом Jenkins, а в GIT репозитории, что обеспечит надежное хранение и контроль
изменений.
Задача логично вытекающая из предыдущей — передача процесса развертывания между разными
командами и частями процесса
Визуализация процесса — Pipeline plugin имеет очень удобный и понятный интерфейс отображения
ранее запущенных сценариев, с возможностью быстрого доступа к логам каждого этапа.

21.

Ansible
Ansible — программное решение с открытым кодом для удаленного
управления конфигурациями, реализованное на языке Python. Ansible берет
на себя всю работу по приведению удаленных серверов в необходимое
состояние посредством ssh протокола, необходимо лишь описать, как достичь
этого состояния с помощью сценариев playbooks, выполненных в формате
yaml.
С помощью Ansible можно решать различные задачи, например:
• Установка/удаление СПО.
• Конфигурирование СПО.
• Создание/удаление пользователей.
• Хранение пользовательских паролей/ключей в защищенном виде (Ansible Vault).
• Развертывание кода вашего ППО.
• Запуск скриптов авто-тестирования в сторонних системах.
• Управление системой создание/удаление контейнеров/виртуальных машин.

22.

Ansible. Преимущества
Преимущества Ansible:
Низкий порог вхождения. Обучиться работе с Ansible можно за очень короткие сроки.
На управляемые узлы не нужно устанавливать никакого дополнительного ПО. Все работает через SSH.
Код программы, написанный на Python, очень прост. Разработка дополнительных модулей не составляет особого труда.
Декларативный язык yaml, на котором пишутся сценарии, также предельно прост.
Встроенная возможность безопасного хранения чувствительной информации (пароли, ключи и тд) — Ansible Vault.
Подробная и весьма просто написанная официальная документация. Она регулярно обновляется. Ее можно найти на официальном
сайте.
Ansible работает не только в режиме push, но и pull, как это делают большинство систем управления (Puppet, Chef).
Имеется возможность последовательного обновления состояния узлов (rolling update).
Сама структура инструмента позволяет создавать отдельные модули — роли, которые могут быть использованы разными командами
в процессепоставки своего ПО. У нас имеется возможность централизованно хранить эти модули и обеспечить их использование
разными командами наразных проектах.

23.

Центральный репозиторий базовых
ролей Ansible
Центральный репозиторий базовых ролей Ansible в СБТ содержит роли Ansible,
которые
централизованно
командами
и
должны
разрабатываются
быть
использованы
и
поддерживаются
разными
командами
выделенными
в
процессе
развертывания каждого проекта в СБТ. По смыслу этот репозиторий – это аналог
официального Ansible Galaxy, но отличается тем, что в нем делятся своими
наработками исключительно сотрудники СБТ и Банка.
Роль Ansible – совокупность последовательности подзадач и всех связанных с этими
подзадачами данных и вспомогательных элементов в одном месте для выполнения
одной функциональной задачи. По сути это логические элементы, с помощью которых
выстраивается весь процесс настройки или развертывания приложения. То есть
будет отдельная роль «Установка WAS», «Установка Nginx», «Установка приложения в
WAS» и тд.

24.

25.

26.

Как происходит процесс
развертывания?
Процесс развертывания в идеале должен содержать следующие логические шаги:
1. Получение всего необходимого для развертывания (ИП — приложение и скрипты
развертывания, конфигурации)
2. Подготовка к восстановлению уже развернутого приложения (опциональный шаг,
зависящий от архитектуры ФП)
3. Подготовка среды для развертывания (все ли папки созданы, права выданы, все ли
скрипты на месте и готовы для развертывания)
4. Выполнение развертывания.
5. Проверки после развертывания (проверка успешности развертывания + проверка
работоспособности (Smoke testing))
6. Если предыдущий шаг не успешен — восстановление приложения на предыдущую
версию (опциональный шаг, зависящий от архитектуры ФП)
7. Информирование заинтересованных лиц.

27.

Как реализован процесс
развертывания?
В целом процесс разделен по следующим инструментам:
Jenkins + Pipeline plugin в виде Groovy кода описывает общий процесс
развертывания.
Ansible роли – это логические элементы развертывания.
GIT должен хранить все скрипты развертывания, конфигурации (сервера
куда ставить – inventory, различные переменные — variables, включая
чувствительные данные – пароли в зашифрованном виде)

28.

29.

Управление конфигурациями сред
Конфигурации сред — это конфигурации, сохраняющие целевое состояние сред как на
системном уровне, так и на уровне приложения. Эти конфигурации необходимы для процесса
развертывания приложения.
Конфигурации сред хранятся в централизованном GIT репозитории. Для каждой ФП создан
отдельный репозиторий с разными ветками — каждая среда развертывания имеет свою
отдельную ветку и своего ответственного. За ветку «dev» отвечает команда разработки, за
ветки «СТ», «ИФТ», «НТ», «ИБ» — инженер развертывания тестовых сред, за ветки «ПСИ» и
«ПРОМ» — представитель отдела промышленной эксплуатации. Кроме того, чтобы зафиксировать
состояние конфигураций и связать их с конкретной версией ИП, должны создаваться тэги (имя
тэга — версия ИП). Таким образом, если появляются изменения в конфигурациях представители
разработки создают тэг, который сообщается всем остальным командам, для того чтобы они
привели свои конфигурации в соответствующее состояние.

30.

31.

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

32.

Интеграции процессов развертывания
и тестирования
Процессы CDL и CDP – процессы, отвечающие за все , что касается поставки уже
готового собранного приложения по всем необходимым этапам тестирования и в
качестве конечной цели — в промышленную эксплуатацию. В рамках этих процессов
обеспечивается гарантия целостности, неизменяемости и уникальности дистрибутива,
проходящего от разработки до промышленных сред.
Однако CDL и CDP не дают гарантию качества и соответствия политикам безопасности
Банка самого дистрибутива. Для реализации этой задачи есть отдельные процессы –
Continuous Testing и тестирование информационной безопасности (ТИБ) . Эти процессы
глубоко интегрированы между собой, что обеспечивает минимизацию рисков ошибок,
сбоев и взломов промышленной среды и как следствие возникновения возможных
нежелательных последствий для Банка.

33.

34.

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

35.

Continuous Delivery
Практика включает в себя:
Хранение инсталляционного пакета (дистрибутива) в централизованном
хранилище.
Гарантирование того, что единый дистрибутив пройдет все циклы
тестирования.
Хранение конфигураций тестовых сред в централизованном версионном
хранилище.
Автоматизацию развертывания приложения на среды тестирования.
Автоматические проверки успешности процесса развертывания.
Интеграцию с инструментами тестирования – функционального,
нагрузочного и динамического тестирования на безопасность.
Тесное сотрудничество команды разработки, команды тестирования (ДК) и
команды эксплуатации (ЦИ, ЦСПС)

Соседние файлы в папке ООП

• #
• #
• #
• #
• #
• #