Среда разработки SMART Process Acceleration - SMART Process Acceleration Development Environment - Wikipedia

ЛОПАТА (SMART Process Acceleration Development Environment) - это инструмент повышения продуктивности и качества разработки программного обеспечения, используемый для создания профессионального программного обеспечения в короткие сроки и с небольшими усилиями. Как видно на диаграмме, SPADE (зеленый значок) автоматизирует многие ручные операции Процесс разработки программного обеспечения. Следовательно, для выполнения полного цикла разработки программного обеспечения требуется меньше времени и усилий.

С SPADE оставшиеся ручные шаги:

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

Возможна автоматизация других этапов, поскольку (бизнес) требования четко определены с помощью метода Требования SMART 2.0.^[1] Затем SPADE использует интеллектуальные алгоритмы, которые включают анализ зависимостей и набор шаблонов проектирования для преобразования этих требований в оптимизированный дизайн бизнес-процесса, включая поток интерактивных и полностью автоматизированных шагов, которые являются частью этого бизнес-процесса.

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

Подробности

Мы объясним создание четких требований на языке Обозначение SMART^[1] что является частью метода Требования SMART 2.0^[1] с последующим объяснением того, как и что SPADE автоматически создаст исходя из этих требований. Мы также объясним создание и выполнение тестовых примеров и типичную архитектуру программного решения, созданного SPADE.

Создание четких требований

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

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

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

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

Обработайте "Заказать продукты" с номером темы ("Заказ": ЗАКАЗАТЬ)

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

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

Визуальная спецификация требования «Заказчик имеет счет-фактуру»

Четко сформулируйте требования. Используйте if-then-else, чтобы определить, «когда» результаты должны применяться или должны быть получены. «Откуда» поступает информация, определяется с помощью ссылок. Например, ORDER.approved - это часть доступной информации, которая либо создается в процессе, либо уже является доступной частью информации. Некоторые требования (результаты) можно уточнить визуально. Справа от вас в электронном письме указано «У клиента есть счет».

 «У клиента есть счет-фактура, если он утвержден» = если ORDER.approved, то «У клиента есть счет-фактура» «Заказ должен быть одобрен, если необходимо» = если «слишком дорого», то «Заказ должен быть утвержден» else ORDER.approved = true "слишком дорого" = ORDER.total> 500

Человек также может быть источником информации, указав «ввод от», за которым следует имя, которое определяет роль этого человека или фактического пользователя. В примере ниже человек с ролью КОНТРОЛЛЕР. Если этим лицам, в свою очередь, нужна информация, чтобы иметь возможность внести этот вклад, вы должны указать, что этот ввод может быть предоставлен «на основе» некоторой другой информации. В данном случае это дата, ПОКУПАТЕЛЬ и СТРОКИ ЗАКАЗА.

 «Заказ должен быть одобрен» = ORDER.approved = ввод от КОНТРОЛЛЕРА на основе # (ORDER.date, ORDER.BUYER, ORDER.LINES)

Фактическое лицо, которое вводит данные во время использования системы (текущий пользователь), также может использоваться как часть информации. В приведенном ниже примере определяется ЗАКАЗ и его атрибуты. Один, если атрибуты называются ПОКУПАТЕЛЕМ, и это заполнено фактическим КЛИЕНТОМ, который (во время фактического выполнения процесса) играет эту роль, другими словами, предоставляя входные данные.

 «Клиент заказал продукты» = В ЗАКАЗАХ существует один ЗАКАЗ с: date = currentDate () ПОКУПАТЕЛЬ = СТРОКИ КЛИЕНТА = «строки заказа» «строки заказа» = В ORDER_LINES существует несколько СТРОК с: PRODUCT = ввод от номера КЛИЕНТА = ввод от КЛИЕНТ

Требования также требуют бизнес-модели или логической модели данных. Большая часть логической модели данных может быть получена из требований. Например, он знает, какие сущности необходимы (ORDERS, ORDER_LINES и PRODUCST), и в некоторых случаях он также может определить тип атрибута. Например, __approved__ может быть только истинным или ложным, потому что он используется как условие, а СТРОКИ должны быть отношениями к ORDER_LINES. Однако некоторые типы не могут быть производными и должны быть явно определены в этой модели данных. Ниже приведен пример этой модели данных.

   ЗАКАЗЫ = дата: дата ПОКУПАТЕЛЬ: ПОЛЬЗОВАТЕЛИ (1) СТРОКИ: ORDER_LINES (*) напротив ЗАКАЗА утвержден: логическое значение: десятичное (10,2) = сумма (LINES.total) сводка: отображаемый текст = '{total} евро на { BUYER.firstName} {BUYER.lastName} на {date} '

   ORDER_LINES = PRODUCT: PRODUCTS (1) number: integer ORDER: ORDERS (1) напротив LINES total: decimal (10,2) = number * PRODUCT.price

   ПРОДУКТЫ = имя: текст цена: десятичное (10,2) резюме: отображаемый текст = '{имя} ({цена} евро)'

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

Реляционные атрибуты: отношения указываются с помощью реляционных атрибутов. Например, BUYER, который содержит 1 экземпляр в стандартной сущности USERS и LINES, которые содержат несколько (*) экземпляров сущности ORDER_LINES и являются противоположностью отношения ORDER (которое является реляционным атрибутом сущности ORDER_LINES).
Расчетные атрибуты: атрибуты могут быть вычислены, что означает, что они не сохраняются, а вычисляются при необходимости. Например, сумма одного экземпляра ORDERS является суммой всех его LINES. Сводка - это текстовое значение, которое представляет собой текст шаблона с некоторыми заполнителями внутри, которые содержат сумму, имя и фамилию ПОКУПАТЕЛЯ и дату.
Показано: это означает, что если системе необходимо отобразить экземпляры из ORDERS, и она не знает, как это сделать, она будет использовать атрибут, отмеченный отображается.

SPADE автоматизирует дизайн и создание кода

Дизайн процесса создается автоматически SPADE.

SPADE выполняет следующие шаги:

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

Форма 1 - введите строки заказа по клиенту

Форма 2 - введите разрешение контролера

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

Создание и запуск тестовых случаев

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

Каждый тестовый сценарий начинается с указания, какой процесс запущен каким пользователем. В этом случае процесс «Заказать продукты» для пользователя «edwinh».

START_PROCESS = Заказать продукты, edwinh

Следующая часть описывает, какие роли и пользователи будут требовать, а затем вводят данные для какой задачи. В этом случае покупатель с именем пользователя Marcusk введет 2 ЛИНИИ, и в каждой строке будет выбранный продукт и несколько продуктов. Вторая задача - для управляющий делами с именем пользователя Эдвин и он наполнит утвержденное истиной.

   # -------- ПЕРВАЯ ПРЕТЕНЗИЯ И ВВЕДИТЕ ПЕРВУЮ ЗАДАЧУ ---------- task01.CLAIM_NEXT_GROUP_TASK = customer, marcusk task01.LINEs = 2 task01.LINEs [0] -c-product = 1 task01.LINEs [0] -c-number = 10 task01.LINEs [1] -c-product = 2 task01.LINEs [1] -c-number = 20 # -------- ПЕРВАЯ ПРЕТЕНЗИЯ И ВХОДИТЕ В 2-Я ЗАДАЧА ---------- task02.CLAIM_NEXT_GROUP_TASK = manager, edwinh task02.approved = true

Следующая часть - это проверка утверждения, достиг ли процесс предсказанного конечного результата. Они не записываются и должны добавляться вручную. В этом примере мы добавили 2 утверждения. Первый проверяет, есть ли еще +1 экземпляр ORDERS с утвержденным атрибутом, заполненным TRUE. Второй проверяет, были ли добавлены +2 новых экземпляра ORDER_LINES.

   ASSERT_PROCESS_VALUE_COUNT_01 = ORDERS.approved = TRUE, +1 ASSERT_PROCESS_ROW_COUNT_02 = ORDER_LINES, +2

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

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

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

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

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

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

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

Глобальная архитектура SPADE и создаваемое ею решение

Полученное программное решение

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

Требования SMART Business: собираются (вручную) и документируются с использованием языка спецификации требований Обозначение SMART.^[1] Это Доменный язык которые можно использовать для определения конечных результатов на основе информации, которые бизнес или организации хотели бы получить.
Автоматически создает дизайны, документы, исходный код: затем на основе требований SPADE автоматически создает проекты, документацию и исходный код, которые могут быть скомпилированы в программное решение.
Пользователи и графический интерфейс: решение может взаимодействовать с авторизованными пользователями на основе ролей различными GUI. В решении уже будет стандартный графический интерфейс для всех функций, но его можно расширить с помощью настраиваемого графического интерфейса. При необходимости GUI обоих типов можно смешивать.
ОТДЫХ / МЫЛО: все функции всегда будут иметь соответствующую службу REST или SOAP, которые используются разными графическими интерфейсами, но также могут использоваться авторизованными внешними системами.
DBAL: сервер также имеет спящий режим или аналогичный уровень абстракции базы данных для связи с базой данных.
Плагины: может использоваться или добавляться на сервер для связи с внешними системами или внешними устройствами. Это позволяет решению также использовать устройства из Интернет вещей домен. Все плагины могут быть вызваны из бизнес-требований, но всегда нетехническим способом. Например, если вы в результате определите ДОКУМЕНТ, SPADE будет знать, что нужно вызвать подключаемый модуль, связанный с объектом ДОКУМЕНТЫ. Плагин фактически создаст и сохранит физический документ.
Особая функциональность: это функциональность, созданная на основе бизнес-требований. С его помощью вы можете создавать самые разные функциональные возможности. Пользователи SPADE могут использовать библиотеку готовых требований, например CRM, HR, сопоставление профилей и финансовые функции. Его можно вставить и отрегулировать в соответствии с конкретными потребностями клиента. Конкретная функциональность может использовать все плагины, а также все общие функциональные возможности для расширения области доступных функций.
Общая функциональность: по умолчанию решение уже оснащено множеством стандартных универсальных функций. Например, DMS, создание документов, автоматическая электронная почта, SMS, обмен сообщениями, расширенный поиск, просмотр данных и экспорт.

Какие действия по разработке программного обеспечения автоматизированы, а какие - вручную?

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

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

История

2000: в 2000 г. Эдвин Хендрикс компании CMG (компания) (теперь часть CGI Group ) разработал метод улучшения процесса под названием Ускорение процесса. В основе этого метода лежал способ полностью однозначного определения желаемого конечного результата бизнес-процесса, а также структурированный подход для определения наиболее оптимального бизнес-процесса, который позволил бы достичь этого конечного результата. Так родилась первая версия Обозначение SMART^[1] (в то время называли Обозначение PA), который является формальным языком, который можно использовать для определения конечных результатов всей цепочки процессов (вместо определения самой цепочки процессов). CMG (компания) использовал этот метод и Обозначение SMART^[1] для нескольких своих проектов и их клиентов.
2007: хотя и успешно, CMG (компания) в то время не было известно о предоставлении консультаций по улучшению процессов. Это было причиной CMG (компания) (в то время слился с Логика ) сосредоточить внимание на сути Ускорение процесса, в результате чего в 2007 году появился метод, улучшающий разработку программного обеспечения, который называется Требования PA SMART (теперь называется Требования SMART 2.0^[1]). С этого момента Требования SMART 2.0^[1] использовался CGI Group и их клиентов, а также других компаний и организаций.
2008: наличие недвусмысленного определения конечного результата цепочки процессов и наличие структурированного подхода к выводу наиболее оптимального процесса из этого конечного результата породило идею создания инструмента, который мог бы считывать конечный результат, выводить наиболее оптимальный процесс из это, и генерировать программное обеспечение для каждого шага в процессе. Эдвин Хендрикс, Маркус Климстра и Нильс Бергсма разработан первый рабочий прототип ЛОПАТА (в то время называемый PA Generator) с использованием [.NET], а также создание систем с использованием архитектуры [.NET].
2010: Логика решил начать разработку коммерческой версии ЛОПАТА.
2011: версия 2.12 SPADE была использована для создания первых двух систем, которые были введены в эксплуатацию. Являясь межведомственной системой учета рабочего времени и системой анонимного голосования, обе используются Логика сам.
2012: создана версия 3 SPADE. Это была первая коммерческая версия SPADE. С тех пор SPADE использовался для создания решений для клиентов. Его часто использовали для воссоздания существующих унаследованные системы из-за короткого времени и затрат, связанных с созданием решений с использованием SPADE. Несмотря на повышенную скорость разработки и низкую стоимость, у SPADE все еще были проблемы с прорезыванием зубов. Это затрудняло оценку фактического времени, необходимого для (повторного) создания решений, что затрудняло планирование проектов. Это был тот же год, когда Логика был приобретен CGI Group.
2015: версия 4 SPADE была впервые использована учениками начальной школы для создания экзаменационной системы. Он показал, что создание требований SMART, а затем обращение к SPADE с просьбой создать для них профессиональную систему было относительно простым делом по сравнению с другими способами создания программного обеспечения. В том же году была запущена небольшая ракета, которая взаимодействовала с программным обеспечением наземной станции, созданным SPADE. Он показал, что SPADE на самом деле может довольно быстро взаимодействовать с внешними устройствами (но еще недостаточно быстро, чтобы его можно было использовать для создания систем реального времени).
2016: в версии 4.4 SPADE было решено большинство начальных проблем, что сделало возможным (воссоздать) большие и сложные системы за короткое время. В настоящее время SPADE расширяется, чтобы обеспечить более простой способ создания и изменения требований, а также более простой способ настройки стандартного графического интерфейса. Это позволит большему количеству людей, не являющихся разработчиками, использовать SPADE для создания решений.

Преимущества, недостатки и соображения

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

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

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

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

Смотрите также

Дисциплинированная гибкая доставка

внешняя ссылка

[:0-1] а ^б ^c ^d ^е ^ж ^грамм ^час Айдынли, Хендрикс, Зандвлит, Требования SMART 2.0. Сду Уитгеверс, 2003, гл. 5.

[1]