CGI POC
1.0.0
Github: https://github.com/cgi-zahid/cgi-poc
Приложение: [https://mycalerts.com]
Получить учетные данные администратора и пример конечного пользователя
Подход CGI к предварительноквалифицированному пулу поставщиков для цифровых услуг-гибкой разработки (PQVP DS-AD), используемых пользовательными методами проектирования, рабочего процесса на основе спринта и современных технологий и технологий с открытым исходным кодом для проектирования и создания микалеров, наша реализация рабочих прототип B. предупреждает и отслеживает их прошлые уведомления. Пользователи могут получать уведомления через услугу коротких сообщений (SMS) и электронную почту на основе уличного размещения и контактной информации, представленной в их профиле пользователя. Mycalerts позволяет авторизованным административным пользователям отслеживать и визуализировать события и отправлять уведомления о специальных событиях чрезвычайных ситуаций и неэкстров.
Мы начали с обзора проекта RFI. CGI основал нашу команду и начал планирование Sprint 0. Мы определили техническую архитектуру и среды, которые мы будем использовать. Мы развернули наши стандартные инструменты разработчика и гибкие ресурсы сотрудничества, чтобы создать приложение «Hello World» (простой страница входа) для проверки нашего технического стека и непрерывной интеграции/непрерывной развертывания (CI/CD).
После получения окончательного RFI наш менеджер продуктов (PM) провел сеанс анализа прототипа. Команда собралась вместе и провела сеанс планирования и размеров, чтобы оценить сложность, интерес команды и риски каждого прототипа. С большим энтузиазмом наша команда выбрала рабочий прототип B.
На основе первоначальных интервью с пользователями PM выбрала три набора данных, которые считаются наиболее актуальными для пользователей CA. Он решил опросить следующие автоматизированные аварийные уведомления: лесные пожары (Служба активных границ пожаров от USGS Geomac - каждые 15 минут), наводнения (река - текущее и прогнозное обслуживание от NOAA - каждые 6 часов) и суровая погода (служба опасности погоды от NOAA - каждые 15 минут).
В начале нашего премьер-министра предоставили свое видение прототипа и дорожную карту высокого уровня для завершения работы. Команда установила роли и обязанности, а также соглашение о сотрудничестве. Мы укрепили и установили наши рабочие отношения команды. Используя дорожную карту и требования к прототипам, команда разработала начальную серию пользовательских историй. Наш премьер -министр расставил приоритеты в этих историях вместе с историями UX/UI и технической настройкой инфраструктуры для создания нашего отставания нашего продукта.
Наш дизайнер UX/пользовательского интерфейса облегчил подход к дизайну пользователя, ориентированное на пользователей, привлекая пользователей на раннем этапе с использованием персоночных интервью и опросов. Мы использовали Angularjs вместе со стандартами и компонентами, наборами из руководства по стилю веб-дизайна США (USWDS) для реализации современного доступного веб-приложения. Мы также проверили на соответствие ADA 508 и WCAG 2.0. Мы использовали пользователей разных возрастов, ролей, опыта и происхождения. Во время Sprint 1 мы взяли интервью у пользователей, и наши результаты были быстро превращены в проволоки, использующие адаптивный дизайн, в котором можно приспособиться как настольные, так и мобильные платформы. Эти проволоки были непрерывно уточнены на основе пользовательского ввода. Наши проволочные потоки обеспечили визуальное представление, чтобы передавать внешний вид прототипа разработчикам. Помимо первоначального дизайна, пользователи были вовлечены в тестирование юзабилити, и их ввод был оценен и приоритет с помощью историй улучшения, которые затем были добавлены в отставание в продукте для включения в последующие спринты.
Мы следовали за гибким процессом (рис. 1) еженедельных циклов спринта, каждый цикл начинается в среду и заканчивается следующим вторником.
Рисунок 1 - Наш гибкий процесс 
Каждую неделю ритуалы спринта включали: Стенд-понедельник-пятница @ 8:45-9:00 утра, облегченный тренером Agile. Члены команды разработчиков сообщили о работе, завершенной с момента последней сессии; Запланированная работа до следующей сессии и любых блокаторов. Идентифицированные блокировщики были очищены гибким тренером и менеджером по доставке. Стенд обеспечил отличный форум для координации по всей команде.
Уход за отставанием - в понедельник, наш премьер -министр рассмотрел и переоценил предметы отставания. Agile Coach и Manager поддержал обзор и подтвердил, что пользовательские истории согласовались с «определением готовой» команды.
Sprint Review - во вторник утром команда представила заполненные пользовательские истории в спринте до премьер -министра для рассмотрения и утверждения. Утвержденные пользовательские истории, соответствующие «определению DODE» команды.
Ретроспектива спринта - во вторник утром команда размышляла о том, как их инструменты, процессы и сверстники выполнялись на недавно завершенном спринте. Каждому члену команды попросили определить одну черту улучшения, которую они хотели видеть, что команда начала делать; Тот, кто они хотели, чтобы команда прекратила свою деятельность, и тот, который они хотели, чтобы команда продолжила. Облегченный тренером Agile, идентифицированные черты начала/остановки/продолжение были консолидированы, а следующие шаги определены командой.
Планирование спринта - во вторник днем, часовая сессия для премьер -министра и команды, интерактивно обсуждала и согласилась с полезной нагрузкой следующего спринта. Размер предметов в спринте был скоординирован гибким тренером и менеджером по доставке. PlanitPoker.com использовался для оценки истории.
Посмотрите на нашу командную фотоальбом для визуальных примеров команды и нашего Agile Process в действии.
С каждой итерацией прототип становился все более выровненным с видением премьер -министра, а также от потребностей наших пользователей. Наша дорожная карта высокого уровня включала несколько пользовательских историй, которые в конечном итоге не были включены в рабочий прототип. Они включали в себя исследования Spike для нативного клиентского приложения iOS и функциональности нативного push -уведомления. В то время как оба не были в опубликованном минимальном жизнеспособном продукте (MVP), они включены в отставку продукта, архитектуру архифактов и исходный код GitHub.
На протяжении всего процесса команда смогла координировать работу и контролировать прогресс, используя нашу доску Scrum. Мы использовали Jira для отслеживания пользовательских историй на электронной доске (а также ошибках) и поддерживали физическую доску в командной комнате. Мы использовали Confluence для обмена документами и Hipchat в качестве инструмента сотрудничества нашей команды. Метрики отслеживались, поэтому команда понимала, как у них дела и потенциальные области для улучшения процесса с каждым спринтом. Метрики показали команде свою скорость развития, техническое отставание и какой процент рассказов на самом деле был реализован с каждым спринтом.
Для каждого технологического решения мы рассматривали открытые варианты, что приводит к стеку, который преимущественно является открытым исходным кодом. Нашей технологической целью было современное веб-приложение на основе браузера, но мы также исследовали возможность нативного мобильного приложения на iOS.
Рисунок 2 - наш технологический стек 
С точки зрения DevOps:
Мы проверили и развернули прототип на Azure Infrastructure Microsoft в качестве решения услуги (IAAS). Мы использовали решение для мониторинга Azure для непрерывного мониторинга инфраструктуры, включая сеть, и новый RELIC для непрерывного мониторинга производительности приложений. Мы использовали данные ключевых показателей производительности (KPI) для точной настройки нашего решения и приложения инфраструктуры.
Наше решение использовало GitHub для документирования кода и модульного тестирования в нашем репозитории общедоступного GitHub. Наша структура Github имеет мастер и интеграционные ветви, а также филиалы. Разработка отдельных историй была сделана в филиале в местной среде. Прежде чем регистрировать код, разработчики выпустили запрос на привлечение для запуска проверки кода. После того, как проверка кода был утвержден, код был объединен в филиал интеграции, что вызвало процесс непрерывной интеграции.
На рисунке 3 отображается представление инструментов и миграцию кода высокого уровня от разработки в производство с использованием нашего процесса CI/CD.
Рисунок 3 - Непрерывная интеграция и развертывание (инструменты) 
Дженкинс взял код из GitHub, построил приложение и выполнил модульные тесты. Если все модульные тесты прошли, Docker создал изображение распределения. Мы использовали модерируемый подход CD в тестовую среду ночью, чтобы не мешать постоянному функциональному тестированию. Специальные развертывания были размещены по мере необходимости. После того, как сборка была развернута для тестирования, наш набор функциональных тестов (с использованием selenium) работал автоматически.
Рисунок 4 - Непрерывная интеграция и развертывание (представление процесса) 
Вот обзор шагов, которые мы выполняли в нашем подходе:
а Разработчик устанавливает свою локальную среду разработки, используя файлы Docker для имитации среды операций и создает филиалы функций из главной ветви GitHub (шаг 0).
беременный Разработчик создает модульные тесты (шаг 1) и записывает соответствующий исходный код (шаг 2) для реализации пользовательской истории/функции.
в Чтобы объединить модульный тест и исходный код, разработчик представляет запрос на вытяжение; Triggers Code Review от разработчика сверстников; Рецензент одобряет/ отрицает слияние в филиал интеграции; Наконец, разработчик разрешает наблюдения за обзором кода. После того, как проверка кода будет одобрен, филиал функций объединяется в филиал интеграции (шаг 4).
дюймовый Тестеры создают автоматические функциональные сценарии (шаг 3), которые объединяются в филиале интеграции (шаг 4).
эн. В заранее определенном графике Дженкинс компилирует исходный код, и все модульные тесты выполняются автоматически (шаг 5).
фон Если модульные тесты не сняты, отправляется уведомление относительно сбоя, и разработчик фиксирует его в филиале функций корреспондента (шаг 15). Шаги 4 и 5 повторяются до тех пор, пока модульные тесты пройдут.
глин После прохождения устройства Jenkins выполняет файлы Docker, чтобы создать изображения Docker для пользовательского интерфейса и бэкэнда (шаг 6).
час Docker выдвигает изображения в реестр Azure (шаг 7), а затем развертывает их в тестовой среде, где функциональные тесты выполняются автоматически (шаг 8).
я. Если функциональные тесты не сняты, уведомление отправляется (шаг 14), и разработчики исправляют проблемы (шаг 15). Шаги 4, 5, 6, 7 и 8 повторяются до прохода функциональных тестов.
Дж. Как только функциональные тесты преуспевают, отправляется уведомление о успешном выполнении теста (шаг 9).
k. QA выполняет специальные/ручные тесты. Если они сняты сбой, разработчик уведомляется, чтобы решить проблему (шаг 15). Шаги 4, 5, 6, 7, 8, 9 и 10 повторяются до прохода специальных тестов.
л. Как только ошибка исправлена, ветвь интеграции объединяется с производственной меткой в главной ветви (шаг 11).
м Наконец, изображение, созданное для тестирования, развернуто в производственной среде (шаг 12).
Наш исходный код структурирован, чтобы следовать нашей распределенной архитектуре и программному обеспечению, используемому для ее реализации. Фронталь хранится в угловой папке, а в папке Dropwizard в папке Dropwizard. У нас также есть папки для автоматических функциональных тестов в папке Selenium.
Пользовательский интерфейс построен с использованием angularjs. В угловой папке папка приложений включает в себя подпапки для изображений, языка, каскадных таблиц, сценариев и представлений. Папка сценариев содержит контроллеры, заводские и услуги. Папка Controllers, в свою очередь, размещает файлы JavaScript, в то время как папка View содержит HTML -файлы. Модульные тесты хранятся отдельно от кода в тестовой папке.
Фронталь общается с бэкэнд с использованием RESTFUL API. Код Frontend, вызывающий службы, находится в подпапке служб под папкой Scripts.
Бэкэнд приложения реализует бизнес -логику, общается с внешними службами, отправляет уведомления и взаимодействует с базой данных. Бэкэнд реализован с использованием Dropwizard, который обеспечивает Java Framework с поддержкой Rest и Junit. Бизнес -логика и конечные точки находятся в папке ресурсов, а внедрение услуг находится в папке услуг.
Приложение также реализует внешние обертки API (реализованные здесь) для извлечения данных из внешних источников данных.
Модульные тесты находятся в тестовой папке.
Приложение связывается с реляционной базой данных (MySQL) с использованием Hibernate. Мы используем стандартные валидации Jaxb Bean для проверки данных. Объекты доступа к данным и объекты модели расположены в папке DAO.
а Назначенный один (1) лидер и дал этому лицу полномочия и ответственность и привлекла к ответственности за качество представленного прототипа
Во время оценки RFI CGI выбрал менеджера по продукту (PM) на основе его технического и управленческого опыта. CGI дал премьер -минимум полномочия по принятию окончательного решения о разработке и разработке прототипа.
беременный Собрал междисциплинарную и совместную команду, которая включает, как минимум, пять (5) категорий труда, как указано в Приложении B: PQVP DS-AD Описания категории категорий
Под руководством премьер -министра, CGI собрал междисциплинарную команду с различными техническими и гибкими возможностями.
Наша команда:
в Понял, что нужно людям, включая людей в процесс разработки и проектирования прототипа;
CGI следовал пользовательскому подходу к проектированию и разработке нашего прототипа. Наш дизайнер UX/пользовательского интерфейса вовлечен пользователям на раннем этапе благодаря использованию личностных интервью и опросов. Результаты интервью были быстро превращены в проволоки. Проводные потоки были уточнены на основе пользовательских опросов, а также для тестирования удобства использования с нашими пользователями. Проводные потоки обеспечили быстрый, визуальный способ общения с разработчиками желаемый прототип внешний вид и чувствовать, что разработка может начаться, как только премьер -министр одобрит первоначальные истории.
Мы применили методы проектирования и инструменты, включая интервью с персоной, разработку проволоков, тестирование удобства использования и Lean UX для разработки нашего пользовательского интерфейса. Чтобы поддержать отзывчивый интерфейс на основе браузера, мы использовали рекомендации от американского веб-дизайна (USWD) для современных веб-стандартов и AngularJ. Применение этих стандартов, наряду с пользователями, позволило нам создать прототип, который был простым и интуитивно понятным для навигации и использования. Мы также протестировали соответствие ADA 508 и WCAG 2.0, используя автоматические инструменты для проверки поддержки адаптивных считывателей и других вариантов низкого видения.
дюймовый Используется не менее трех (3) методов «ориентированного на пользователь» и/или инструментов;
Мы использовали персональные интервью, проволочные потоки и удобство использования в качестве основных инструментов для разработки дизайна для нашего прототипа, который был сосредоточен на потребностях и потребностях наших пользователей.
эн. Использовал GitHub для документирования кода Commits;
Коммитами можно посмотреть в GitHub: https://github.com/cgi-zahid/cgi-poc
фон Использовал Swagger для документирования API RESTful, и предоставил ссылку на API Swagger;
Вся связь с средним уровнем была сделана с использованием API REST. Средний уровень обнажает API REST с использованием JAX RX и задокументирован в Swagger.
глин Выполнил раздел 508 Закона об американцах с ограниченными возможностями и WCAG 2.0;
В рамках нашего удобства для использования, мы протестировали на соответствие 508 и WCAG 2.0. Мы использовали автоматическое тестирование для проверки на читаемость и низкое зрение. Мы обратились к ошибкам как часть нашего процесса отставания. Другие результаты тестирования были оценены, чтобы определить, что следует добавить к отставанию, и те, которые не применялись к нашему прототипу.
Мы использовали ACTF Adesigner для нашего 508 -го тестирования.
час Создано или использовало руководство по стилю дизайна и/или библиотеку шаблонов;
UX/UI создал руководство по стилю с использованием стандартов веб -дизайна США. Наша цветовая схема была выбрана на основе цветов штата Калифорния и одобрена отзывы пользователей. Применение стандартов веб -дизайна США наряду с вводом пользователей позволило нам создать прототип, который был простым и интуитивно понятным для навигации и использования.
я. Выполнены в юзабилити -тестировании с людьми;
В рамках нашего подхода, ориентированного на пользователя, мы включили в наш процесс тестирование юзабилити. Тестирование удобства использования проводилось с помощью пользовательских опросов на наших каркасах, а также отзывы пользователей, которые проверяли наш прототип на протяжении всех наших спринтов. Обратная связь из удобства использования тестов оценивалась PM и Desticer, чтобы определить, что включать в отставание. На основе направления PM новые истории были созданы, приоритетными и помещены в наше отставание.
Дж. Использовал итеративный подход, где обратная связь информировала последующую работу или версии прототипа;
В каждом спринте входные данные, полученные от менеджера продукта, тестировщиков юзабилити и дефектов, выявленных во время тестирования, были оценены, приоритеты и включены в отставание в рамках нашего итерационного подхода. С каждой демонстрацией прототип становился все более и более согласованным с видением премьер -министра, а также от потребностей наших пользователей.
k. Создал прототип, который работает на нескольких устройствах, и представляет собой отзывчивый дизайн;
Наш код тестировал с использованием нескольких устройств и работает с несколькими веб -браузерами. Кроме того, наш код был протестирован с использованием устройств Apple и Android.
Мы проверили:
л. Используется как минимум пять (5) современных и открытых технологий, независимо от архитектурного слоя (фронт, бэкэнд и т. Д.);
Мы использовали следующие шесть (6) современных и открытых технологий:
Список всех наших технологий предоставлен: список технологий. Ряды, выделенные зеленым, на электронной таблице - современные технологии с открытым исходным кодом.
м Развернул прототип на инфраструктуре в качестве услуги (IAAS) или платформы в качестве поставщика услуг (PAAS) и указал, какой поставщик они использовали;
Мы использовали Azure в качестве нашего поставщика IAAS.
не Разработали автоматические модульные тесты для их кода;
Прежде чем проверить код в разработчиках филиалов функций, сделайте запрос на вытягивание, чтобы запустить проверку кода. После того, как проверка кода будет одобрен, код объединяется в филиал интеграции, которая запускает процесс непрерывного развертывания.
о. Настройка или использовала систему непрерывной интеграции для автоматизации выполнения тестов и непрерывно развернуть их код для их поставщика IAAS или PAAS;
Мы использовали Дженкинса для непрерывной интеграции. Он захватывает код из GitHub, компилируется и выполняет тесты. Если код проходит тесты, то Docker создает изображение. Изображение развернуто в среде тестирования системы, где функциональный тест на конечный к конечному тестируется с использованием селена.
п. Настройка или использованное управление конфигурацией;
Реестры контейнеров Azure использовались для хранения и управления нашими изображениями Docker, позволяя нам управлять конфигурацией
Q. Настройка или использование непрерывного мониторинга;
Azure и New Relic были использованы для постоянного мониторинга здоровья окружающей среды и применения
ведущий Развернули свое программное обеспечение в контейнере с открытым исходным кодом, таким как Docker (т.е., используя виртуализацию уровня операционной системы);
Мы развернули наше программное обеспечение с помощью Docker
с Обеспечил достаточную документацию для установки и запуска их прототипа на другой машине;
Ниже приведена ссылка на наши инструкции по установке.
Инструкции
Т Прототип и базовые платформы, используемые для создания и запуска прототипа, открыто лицензированы и бесплатны.
Мы использовали открыто лицензированные и бесплатные платформы
Список инструментов
Наш процесс дизайна и разработки нашего прототипа последовал и соответствовал многим стандартам, изложенным в американском пьесе Digital Services. Мы предоставили подробный документ на GitHub, который связан с нашим доказательством, а также на наш ответ на каждый элемент.
Наши ответы на воспроизведение цифровых услуг в США
