CGI POC
1.0.0
Github: https://github.com/cgi-zahid/cgi-poc
Aplikasi: [https://mycalerts.com]
Dapatkan admin dan sampel kredensial pengguna akhir
Pendekatan CGI terhadap kumpulan vendor pra-kualifikasi untuk layanan digital-upaya pengembangan gesit (PQVP DS-AD) menggunakan teknik desain pengguna-sentris, alur kerja pembangunan berbasis sprint dan teknologi modern dan sumber terbuka untuk merancang dan membangun mycalert, penerapan prototipe kerja kami B. Mycalerts memungkinkan penduduk California untuk mendirikan dan mengelola Pengguna Pengguna, Pelataran Pengguna Kerja. Lacak pemberitahuan masa lalu mereka. Pengguna dapat menerima pemberitahuan melalui Layanan Pesan Singkat (SMS) dan email berdasarkan lokasi jalanan dan informasi kontak yang disediakan di profil pengguna mereka. MyCalerts memungkinkan pengguna administratif resmi untuk melacak dan memvisualisasikan acara dan mengirimkan pemberitahuan peristiwa darurat dan non-darurat ad hoc.
Kami mulai dengan ulasan rancangan RFI. CGI mendirikan tim kami dan memulai perencanaan sprint 0. Kami menentukan arsitektur teknis dan lingkungan yang akan kami gunakan. Kami menggunakan alat pengembang standar dan sumber daya kolaborasi yang gesit, untuk membangun aplikasi "Hello World" (halaman login sederhana) untuk menguji kerangka kerja teknis dan integrasi kontinu/kerangka kerja kontinu (CI/CD).
Setelah menerima RFI akhir, manajer produk kami (PM) memimpin sesi analisis prototipe. Tim datang bersama dan mengadakan sesi perencanaan dan ukuran untuk mengevaluasi kompleksitas, minat tim, dan risiko masing -masing prototipe. Dengan antusiasme yang luar biasa, tim kami memilih prototipe B.
Berdasarkan wawancara pengguna awal, PM memilih tiga dataset yang dianggap paling relevan bagi pengguna CA. Dia memilih untuk melakukan polling untuk pemberitahuan darurat otomatis berikut: kebakaran hutan (layanan batas kebakaran aktif dari USGS Geomac - setiap 15 menit), banjir (pengukur sungai - layanan saat ini dan perkiraan dari NOAA - setiap 6 jam) dan cuaca buruk (layanan bahaya cuaca dari NOAA - setiap 15 menit).
Pada kickoff, PM kami memberikan visinya untuk prototipe dan peta jalan tingkat tinggi untuk menyelesaikan pekerjaan. Tim menetapkan peran dan tanggung jawab serta perjanjian tim kolaboratif. Kami memperkuat dan menjalin hubungan kerja tim kami. Menggunakan persyaratan peta jalan dan prototipe, tim mengembangkan serangkaian cerita pengguna awal. PM kami memprioritaskan cerita -cerita ini bersama dengan UX/UI dan cerita pengaturan infrastruktur teknis untuk membuat simpanan produk kami.
Desainer UX/UI kami memfasilitasi pendekatan desain pengguna yang digerakkan pengguna dengan melibatkan pengguna sejak dini melalui penggunaan wawancara dan survei persona. Kami memanfaatkan AngularJS bersama dengan standar dan komponen yang diatur dari Panduan Gaya Desain Web (USWDS) AS untuk mengimplementasikan aplikasi web modern yang dapat diakses. Kami juga menguji Kepatuhan ADA 508 dan WCAG 2.0. Kami mengetuk pengguna dari berbagai usia, peran, pengalaman, dan latar belakang. Selama Sprint 1 kami mewawancarai pengguna dan hasil kami dengan cepat diubah menjadi wireflows yang memanfaatkan desain responsif yang mengakomodasi platform desktop dan seluler. Wireflow ini terus disempurnakan berdasarkan input pengguna. Wireflow kami menyediakan visual untuk mengomunikasikan tampilan dan nuansa prototipe kepada pengembang. Di luar desain awal, pengguna terlibat melalui pengujian kegunaan dan inputnya dievaluasi dan diprioritaskan melalui kisah -kisah perbaikan yang kemudian ditambahkan dalam simpanan produk untuk dimasukkan dalam sprint berikutnya.
Kami mengikuti proses gesit (Gambar 1) dari siklus sprint mingguan, dengan setiap siklus dimulai pada hari Rabu dan mengakhiri Selasa berikutnya.
Gambar 1 - Proses Agile Kami 
Setiap minggu ritual sprint termasuk: Stand-up-Senin-Jumat @ 8:45-9:00 pagi difasilitasi oleh pelatih yang gesit. Anggota tim pengembangan melaporkan pekerjaan selesai sejak sesi terakhir; Pekerjaan yang direncanakan sebelum sesi berikutnya dan pemblokir apa pun. Blocker yang diidentifikasi dibersihkan oleh pelatih gesit dan manajer pengiriman. Stand-up menyediakan forum yang bagus untuk koordinasi di seluruh tim.
Backlog Grooming - Senin, PM kami meninjau dan mengulangi item backlog. Pelatih Agile dan Manajer Pengiriman mendukung ulasan dan mengkonfirmasi kisah pengguna yang disepakati dengan "definisi siap" tim.
Sprint Review - Selasa pagi, tim mempresentasikan cerita pengguna yang selesai dalam sprint ke PM untuk ditinjau dan disetujui. Kisah pengguna yang disetujui selaras dengan "definisi selesai" tim.
Sprint Retrospective - Selasa pagi, tim merefleksikan bagaimana alat, proses, dan rekan mereka berkinerja di sprint yang baru saja selesai. Setiap anggota tim diminta untuk mengidentifikasi satu sifat perbaikan yang ingin mereka lihat mulai lakukan; Satu yang mereka ingin tim berhenti lakukan dan yang mereka ingin tim melanjutkan. Difasilitasi oleh pelatih gesit, ciri -ciri Start/Stop/Lanjutan yang diidentifikasi dikonsolidasikan dan langkah -langkah selanjutnya yang ditentukan oleh tim.
Perencanaan Sprint - Selasa sore, sesi satu jam untuk PM dan tim secara interaktif membahas dan menyetujui muatan sprint berikutnya. Ukuran barang -barang dalam sprint dikoordinasikan oleh pelatih gesit dan manajer pengiriman. Planitpoker.com digunakan untuk estimasi cerita.
Lihat album foto tim kami untuk contoh visual tim dan proses gesit kami beraksi.
Dengan setiap iterasi, prototipe menjadi semakin selaras dengan visi PM, serta kebutuhan pengguna kami. Peta jalan tingkat tinggi kami mencakup beberapa cerita pengguna yang pada akhirnya tidak termasuk dalam prototipe kerja. Ini termasuk penelitian lonjakan untuk aplikasi klien asli iOS dan fungsionalitas pemberitahuan push asli. Sementara keduanya tidak berada dalam produk minimum yang layak (MVP), mereka termasuk dalam simpanan produk, artefak arsitektur dan kode sumber github.
Sepanjang proses, tim dapat mengoordinasikan pekerjaan dan memantau kemajuan dengan menggunakan papan scrum kami. Kami menggunakan Jira untuk melacak cerita pengguna di papan elektronik (serta bug), dan memelihara papan fisik di ruang tim. Kami menggunakan Confluence untuk berbagi dokumen dan Hipchat sebagai alat kolaborasi tim kami. Metrik dilacak sehingga tim mengerti bagaimana mereka melakukan dan area potensial untuk peningkatan proses dengan setiap sprint. Metrik menunjukkan kecepatan pengembangan mereka, backlog teknis, dan berapa persen poin cerita yang sebenarnya diimplementasikan dengan setiap sprint.
Untuk setiap keputusan teknologi, kami mempertimbangkan opsi terbuka, menghasilkan tumpukan yang sebagian besar open source. Target teknologi kami adalah aplikasi web modern berbasis browser, tetapi kami juga menyelidiki kemungkinan aplikasi seluler asli di iOS.
Gambar 2 - Tumpukan Teknologi Kami 
Dari sudut pandang DevOps:
Kami menguji dan menggunakan prototipe pada infrastruktur Azure Microsoft sebagai solusi layanan (IAAS). Kami menggunakan solusi pemantauan Azure untuk pemantauan infrastruktur berkelanjutan termasuk jaringan, dan peninggalan baru untuk pemantauan kinerja aplikasi berkelanjutan. Kami menggunakan data indikator kinerja utama (KPI) untuk menyempurnakan solusi dan aplikasi infrastruktur kami.
Solusi kami menggunakan GitHub untuk mendokumentasikan kode dan unit uji berkomitmen di repositori GitHub publik kami. Struktur GitHub kami memiliki cabang master dan integrasi serta cabang fitur. Pengembangan cerita individu dilakukan di cabang fitur di lingkungan lokal. Sebelum memeriksa kode, pengembang mengeluarkan permintaan tarik untuk memicu tinjauan kode. Setelah tinjauan kode disetujui, kode digabungkan ke dalam cabang integrasi, memicu proses integrasi kontinu.
Gambar 3 menampilkan tampilan alat dan migrasi kode tingkat tinggi dari pengembangan ke produksi menggunakan proses CI/CD kami.
Gambar 3 - Integrasi dan Penyebaran Berkelanjutan (Alat) 
Jenkins mengambil kode dari GitHub, membangun aplikasi, dan mengeksekusi tes unit. Jika semua tes unit berlalu, Docker membuat gambar distribusi. Kami menggunakan pendekatan CD yang dimoderasi ke lingkungan pengujian setiap malam untuk menghindari mengganggu pengujian fungsional yang berkelanjutan. Penyebaran ad hoc ditampung sesuai kebutuhan. Setelah bangunan digunakan untuk menguji, rangkaian uji fungsional kami (menggunakan selenium) berjalan secara otomatis.
Gambar 4 - Integrasi dan Penempatan Berkelanjutan (Tampilan Proses) 
Berikut adalah gambaran tentang langkah -langkah yang kami ikuti dalam pendekatan kami:
A. Pengembang menetapkan lingkungan pengembangan lokal mereka menggunakan file Docker untuk meniru lingkungan operasi dan menciptakan cabang fitur dari cabang GitHub Master (Langkah 0).
B. Pengembang membuat tes unit (Langkah 1) dan menulis kode sumber yang sesuai (Langkah 2) untuk mengimplementasikan cerita/fitur pengguna.
C. Untuk menggabungkan tes unit dan kode sumber, pengembang mengirimkan permintaan tarik; Tinjauan kode pemicu oleh pengembang sebaya; Peninjau menyetujui/ menolak penggabungan ke dalam cabang integrasi; Akhirnya pengembang menyelesaikan pengamatan tinjauan kode. Setelah tinjauan kode disetujui, cabang fitur digabungkan ke dalam cabang integrasi (Langkah 4).
D. Penguji membuat skrip fungsional otomatis (Langkah 3), yang digabungkan dalam cabang integrasi (Langkah 4).
e. Pada jadwal yang telah ditentukan, Jenkins mengkompilasi kode sumber dan semua tes unit dijalankan secara otomatis (Langkah 5).
F. Jika tes unit gagal, pemberitahuan dikirim mengenai kegagalan dan pengembang memperbaikinya di cabang fitur koresponden (langkah 15). Langkah 4 dan 5 diulangi sampai unit tes lulus.
G. Setelah unit tes lulus, Jenkins mengeksekusi file Docker untuk membangun gambar Docker untuk UI dan backend (langkah 6).
H. Docker mendorong gambar ke Azure Registry (Langkah 7), dan kemudian menyebarkannya ke lingkungan pengujian di mana tes fungsional dieksekusi secara otomatis (Langkah 8).
Saya. Jika tes fungsional gagal, pemberitahuan dikirim (Langkah 14), dan pengembang memperbaiki masalah (Langkah 15). Langkah 4, 5, 6, 7 dan 8 diulangi sampai tes fungsional lulus.
J. Setelah tes fungsional berhasil, pemberitahuan dikirim mengenai eksekusi pengujian yang berhasil (Langkah 9).
k. QA melakukan tes ad-hoc/manual. Jika ini gagal, pengembang diberitahu untuk memperbaiki masalah (Langkah 15). Langkah 4, 5, 6, 7, 8, 9 dan 10 diulangi sampai tes ad-hoc lulus.
l. Setelah kesalahan diperbaiki, cabang integrasi digabungkan dengan label produksi di cabang master (langkah 11).
M. Akhirnya, gambar yang dibuat untuk pengujian digunakan ke lingkungan produksi (Langkah 12).
Kode sumber kami disusun untuk mengikuti arsitektur terdistribusi kami dan perangkat lunak yang digunakan untuk mengimplementasikannya. Frontend disimpan di folder sudut, dan backend di folder dropwizard. Kami juga memiliki folder untuk tes fungsional otomatis di folder selenium.
UI dibangun menggunakan AngularJS. Di dalam folder sudut, folder aplikasi termasuk subfolder untuk gambar, bahasa, cascading stylesheet, skrip, dan tampilan. Folder skrip berisi pengontrol, pabrik, dan layanan. Folder pengontrol pada gilirannya meng -host file JavaScript, sedangkan folder tampilan berisi file HTML. Tes unit disimpan secara terpisah dari kode di folder tes.
Frontend berkomunikasi dengan backend menggunakan API RESTful. Kode frontend yang memohon layanan berada di subfolder Layanan di bawah folder skrip.
Aplikasi Backend mengimplementasikan logika bisnis, berkomunikasi dengan layanan eksternal, mengirimkan pemberitahuan, dan berinteraksi dengan database. Backend diimplementasikan menggunakan DropWizard, yang menyediakan kerangka kerja Java dengan dukungan istirahat dan junit. Logika bisnis dan titik akhir ada di folder sumber daya, dan implementasi layanan ada di folder layanan.
Aplikasi ini juga mengimplementasikan pembungkus API eksternal (diimplementasikan di sini) untuk mengambil data dari sumber data eksternal.
Tes unit berada di folder tes.
Aplikasi berkomunikasi dengan database relasional (MySQL) menggunakan Hibernate. Kami menggunakan validasi kacang JAXB standar untuk validasi data. Objek akses data dan objek model terletak di folder DAO.
A. Ditugaskan satu (1) pemimpin dan memberi orang itu otoritas dan tanggung jawab dan meminta pertanggungjawaban orang itu atas kualitas prototipe yang diserahkan
Selama evaluasi RFI, CGI memilih manajer produk (PM) berdasarkan pengalaman teknis dan manajemennya. CGI memberi Otoritas Pengambilan Keputusan Akhir PM pada desain dan pengembangan prototipe.
B. Mengumpulkan tim multidisiplin dan kolaboratif yang mencakup, minimal, lima (5) kategori tenaga kerja sebagaimana diidentifikasi dalam Lampiran B: PQVP DS-AD Kategori Kategori Tenaga Kerja Deskripsi
Di bawah kepemimpinan PM, CGI mengumpulkan tim multidisiplin dengan berbagai kemampuan teknis dan gesit.
Tim kami:
C. Memahami apa yang dibutuhkan orang, dengan memasukkan orang -orang dalam pengembangan prototipe dan proses desain;
CGI mengikuti pendekatan pengguna-sentris untuk desain dan pengembangan prototipe kami. Perancang UX/UI kami melibatkan pengguna lebih awal melalui penggunaan wawancara dan survei Persona. Hasil wawancara dengan cepat berubah menjadi wireflows. Wireflow disempurnakan berdasarkan survei pengguna serta pengujian kegunaan dengan pengguna kami. Wireflows memberikan cara visual yang cepat dan cepat untuk berkomunikasi kepada pengembang tampilan prototipe yang diinginkan dan merasa pengembangan dapat dimulai setelah PM menyetujui cerita awal.
Kami menerapkan teknik dan alat desain termasuk wawancara persona, pengembangan wireflow, pengujian kegunaan, dan lean UX untuk mengembangkan UI kami. Untuk mendukung antarmuka berbasis browser yang responsif, kami memanfaatkan pedoman dari Desain Web AS (USWD) untuk standar web modern dan AngularJS. Menerapkan standar -standar ini, bersama dengan input dari pengguna, memungkinkan kami untuk membangun prototipe yang sederhana dan intuitif untuk dinavigasi dan digunakan. Kami juga menguji Kepatuhan ADA 508 dan WCAG 2.0, menggunakan alat otomatis untuk menguji dukungan pembaca adaptif dan opsi low vision lainnya.
D. Menggunakan setidaknya minimal tiga (3) teknik dan/atau alat “desain pengguna-sentris”;
Kami menggunakan wawancara persona, wireflow, dan uji kegunaan sebagai alat utama kami untuk mengembangkan desain untuk prototipe kami yang berfokus pada kebutuhan dan keinginan pengguna kami.
e. Bekas GitHub untuk mendokumentasikan Kode Komit;
Komit dapat dilihat di GitHub: https://github.com/cgi-zahid/cgi-poc
F. Menggunakan Swagger untuk mendokumentasikan API yang tenang, dan memberikan tautan ke API Swagger;
Semua komunikasi dengan tingkat menengah dilakukan dengan menggunakan API REST. Tingkat Tengah memperlihatkan API REST menggunakan Jax RX dan didokumentasikan dengan kesombongan.
G. Dipatuhi dengan Bagian 508 dari Undang -Undang Amerika dengan Disabilitas dan WCAG 2.0;
Sebagai bagian dari pengujian kegunaan kami, kami menguji kepatuhan 508 dan WCAG 2.0. Kami menggunakan pengujian otomatis untuk menguji keterbacaan dan penglihatan rendah. Kami membahas kesalahan sebagai bagian dari proses backlog kami. Hasil pengujian lainnya dievaluasi untuk menentukan mana yang akan ditambahkan ke jaminan dan hasil yang tidak berlaku untuk prototipe kami.
Kami menggunakan ACTF Adesigner untuk pengujian 508 kami.
H. Membuat atau menggunakan panduan gaya desain dan/atau perpustakaan pola;
UX/UI membuat panduan gaya menggunakan standar desain web AS. Skema warna kami dipilih berdasarkan warna negara bagian California dan disetujui oleh umpan balik pengguna. Menerapkan standar desain web AS bersama dengan input dari pengguna memungkinkan kami untuk membangun prototipe yang sederhana dan intuitif untuk dinavigasi dan digunakan.
Saya. Melakukan tes kegunaan dengan orang -orang;
Sebagai bagian dari pendekatan sentris pengguna kami, kami memasukkan pengujian kegunaan ke dalam proses kami. Pengujian kegunaan dilakukan melalui survei pengguna pada wireframes kami serta umpan balik dari pengguna yang menguji prototipe kami di seluruh sprint kami. Umpan balik dari tes kegunaan dievaluasi oleh perancang PM dan UX untuk menentukan apa yang akan dimasukkan dalam jaminan. Berdasarkan arahan PM, cerita baru dibuat, diprioritaskan, dan ditempatkan di jaminan kami.
J. Menggunakan pendekatan berulang, di mana umpan balik menginformasikan pekerjaan berikutnya atau versi prototipe;
Dalam setiap sprint, input yang diterima dari manajer produk, penguji kegunaan, dan cacat yang diidentifikasi selama pengujian dievaluasi, diprioritaskan, dan dimasukkan ke dalam simpanan sebagai bagian dari pendekatan berulang kami. Dengan setiap demo prototipe menjadi semakin selaras dengan visi PM serta kebutuhan pengguna kami.
k. Menciptakan prototipe yang berfungsi pada banyak perangkat, dan menyajikan desain yang responsif;
Kode kami telah menguji menggunakan beberapa perangkat dan berfungsi dengan beberapa browser web. Selain itu kode kami telah diuji menggunakan perangkat Apple dan Android.
Kami menguji:
l. Menggunakan setidaknya lima (5) teknologi modern dan open-source, terlepas dari lapisan arsitektur (frontend, backend, dll.);
Kami menggunakan enam (6) teknologi modern dan open-source berikut:
Daftar semua teknologi kami disediakan: Daftar Teknologi. Baris yang disorot berwarna hijau di spreadsheet adalah teknologi modern dan open source.
M. Menyebarkan prototipe pada infrastruktur sebagai penyedia layanan (IaaS) atau platform sebagai layanan (PAAS), dan menunjukkan penyedia mana yang mereka gunakan;
Kami menggunakan Azure sebagai penyedia IaaS kami.
N. Mengembangkan tes unit otomatis untuk kode mereka;
Sebelum memeriksa kode ke pengembang cabang fitur melakukan permintaan tarik untuk memicu tinjauan kode. Setelah tinjauan kode disetujui kode digabungkan ke dalam cabang integrasi yang memicu proses penyebaran kontinu.
Hai. Mengatur atau menggunakan sistem integrasi kontinu untuk mengotomatisasi menjalankan tes dan terus menggunakan kode mereka ke IAAs atau penyedia PaaS mereka;
Kami menggunakan Jenkins untuk integrasi berkelanjutan. Ini mengambil kode dari GitHub dan mengkompilasi dan menjalankan tes. Jika kode lulus tes maka Docker membuat gambar. Gambar digunakan ke lingkungan uji sistem di mana uji fungsional ujung ke ujung dilakukan menggunakan selenium.
P. Pengaturan atau manajemen konfigurasi yang digunakan;
Pendaftaran wadah Azure digunakan untuk menyimpan dan mengelola gambar Docker kami yang memungkinkan kami untuk mengelola konfigurasi
Q. Mengatur atau menggunakan pemantauan kontinu;
Azure dan peninggalan baru digunakan untuk terus memantau kesehatan lingkungan dan aplikasi
R. Menggunakan perangkat lunak mereka dalam wadah open source, seperti Docker (yaitu, menggunakan virtualisasi tingkat sistem operasi);
Kami menggunakan perangkat lunak kami menggunakan Docker
S. Memberikan dokumentasi yang cukup untuk menginstal dan menjalankan prototipe mereka di mesin lain;
Di bawah ini adalah tautan ke instruksi pemasangan kami.
Instruksi
T. Prototipe dan platform yang mendasari yang digunakan untuk membuat dan menjalankan prototipe secara terbuka berlisensi dan gratis.
Kami menggunakan platform berlisensi terbuka dan gratis
Daftar alat
Proses kami untuk desain dan pengembangan prototipe kami mengikuti dan memenuhi banyak standar yang diuraikan dalam Playbook Layanan Digital AS. Kami memberikan dokumen terperinci tentang GitHub yang menghubungkan bukti kami, serta respons kami terhadap setiap item.
Respons Buku Playbook Layanan Digital AS kami
