CGI POC
1.0.0
GitHub: https://github.com/cgi-zahid/cgi-poc
แอปพลิเคชัน: [https://mycalerts.com]
รับข้อมูลรับรองผู้ดูแลระบบและตัวอย่าง
แนวทางของ CGI ในการใช้งานผู้ขายที่ผ่านการรับรองสำหรับบริการดิจิตอล-การพัฒนาแบบ Agile (PQVP DS-AD) ใช้เทคนิคการออกแบบที่เน้นผู้ใช้เป็นศูนย์กลางเวิร์กโฟลว์การพัฒนาตามการวิ่งและเทคโนโลยีที่ทันสมัยและโอเพ่นซอร์ส การแจ้งเตือนและติดตามการแจ้งเตือนในอดีต ผู้ใช้สามารถได้รับการแจ้งเตือนผ่านบริการข้อความสั้น ๆ (SMS) และอีเมลตามข้อมูลที่ตั้งและข้อมูลการติดต่อที่ให้ไว้ในโปรไฟล์ผู้ใช้ของพวกเขา MyCalerts ช่วยให้ผู้ใช้ที่ได้รับอนุญาตสามารถติดตามและแสดงภาพเหตุการณ์และส่งการแจ้งเตือนของเหตุการณ์ฉุกเฉินเฉพาะกิจและที่ไม่ใช่ฉุกเฉิน
เราเริ่มต้นด้วยการทบทวนร่าง RFI CGI ก่อตั้งทีมของเราและเริ่มวางแผน 0 เราพิจารณาสถาปัตยกรรมทางเทคนิคและสภาพแวดล้อมที่เราจะใช้ เราปรับใช้เครื่องมือนักพัฒนามาตรฐานและทรัพยากรการทำงานร่วมกันแบบ Agile เพื่อสร้างแอปพลิเคชัน“ Hello World” (หน้าเข้าสู่ระบบอย่างง่าย) เพื่อทดสอบสแต็กทางเทคนิคของเราและกรอบการรวมการรวม/การปรับใช้อย่างต่อเนื่อง (CI/CD)
เมื่อได้รับ RFI สุดท้ายผู้จัดการผลิตภัณฑ์ของเรา (PM) นำเซสชันการวิเคราะห์ต้นแบบ ทีมมารวมกันและจัดให้มีการวางแผนและปรับขนาดเพื่อประเมินความซับซ้อนความสนใจของทีมและความเสี่ยงของต้นแบบแต่ละต้น ด้วยความกระตือรือร้นที่ยอดเยี่ยมทีมของเราเลือกต้นแบบการทำงาน B.
จากการสัมภาษณ์ผู้ใช้ครั้งแรก PM ได้เลือกชุดข้อมูลสามชุดที่เกี่ยวข้องกับผู้ใช้ CA มากที่สุด เขาเลือกที่จะสำรวจความคิดเห็นสำหรับการแจ้งเตือนฉุกเฉินอัตโนมัติดังต่อไปนี้: ไฟป่า (บริการเขตไฟที่ใช้งานจาก USGS Geomac - ทุก ๆ 15 นาที) น้ำท่วม (มาตรวัดแม่น้ำ - บริการปัจจุบันและการพยากรณ์จาก NOAA - ทุก 6 ชั่วโมง) และสภาพอากาศที่รุนแรง
ที่สนาม PM ของเราให้วิสัยทัศน์ของเขาสำหรับต้นแบบและแผนงานระดับสูงสำหรับการทำงานให้เสร็จ ทีมได้กำหนดบทบาทและความรับผิดชอบรวมถึงข้อตกลงทีมงานร่วมกัน เราเสริมสร้างและสร้างความสัมพันธ์ในการทำงานของทีม การใช้ Roadmap และข้อกำหนดต้นแบบทีมได้พัฒนาเรื่องราวเริ่มต้นของเรื่องราวผู้ใช้ PM ของเราจัดลำดับความสำคัญเรื่องราวเหล่านี้พร้อมกับ UX/UI และเรื่องราวการตั้งค่าโครงสร้างพื้นฐานทางเทคนิคเพื่อสร้างงานในมือของเรา
นักออกแบบ UX/UI ของเราอำนวยความสะดวกในการเป็นศูนย์กลางของผู้ใช้ - วิธีการออกแบบที่ผู้ใช้ขับเคลื่อนโดยการมีส่วนร่วมของผู้ใช้ในช่วงต้นผ่านการใช้การสัมภาษณ์ Persona และการสำรวจ เราใช้ประโยชน์จาก AngularJs พร้อมกับมาตรฐานและชุดส่วนประกอบจากคู่มือสไตล์ US Design (USWDS) เพื่อใช้แอปพลิเคชันเว็บที่เข้าถึงได้ทันสมัย นอกจากนี้เรายังทดสอบการปฏิบัติตาม ADA 508 และ WCAG 2.0 เราแตะต้องผู้ใช้ทุกวัยบทบาทประสบการณ์และภูมิหลัง ในช่วง Sprint 1 เราสัมภาษณ์ผู้ใช้และผลลัพธ์ของเราก็กลายเป็น Wireflows อย่างรวดเร็วซึ่งใช้ประโยชน์จากการออกแบบที่ตอบสนองได้ทั้งเดสก์ท็อปและแพลตฟอร์มมือถือ Wireflows เหล่านี้ได้รับการปรับปรุงอย่างต่อเนื่องตามอินพุตของผู้ใช้ Wireflows ของเราให้ภาพเพื่อสื่อสารรูปลักษณ์และความรู้สึกของต้นแบบให้กับนักพัฒนา นอกเหนือจากการออกแบบเบื้องต้นผู้ใช้มีส่วนร่วมผ่านการทดสอบการใช้งานและอินพุตของพวกเขาได้รับการประเมินและจัดลำดับความสำคัญผ่านเรื่องราวการปรับปรุงซึ่งเพิ่มเข้ามาในงานค้างของผลิตภัณฑ์เพื่อรวมไว้ในการวิ่งครั้งต่อไป
เราทำตามกระบวนการว่องไว (รูปที่ 1) ของรอบการวิ่งทุกสัปดาห์โดยแต่ละรอบเริ่มต้นในวันพุธและสิ้นสุดในวันอังคารถัดไป
รูปที่ 1 - กระบวนการว่องไวของเรา 
ในแต่ละสัปดาห์พิธีกรรม Sprint รวมอยู่ด้วย: Stand-Up-วันจันทร์ถึงวันศุกร์ @ 8:45-9:00 น. อำนวยความสะดวกโดยโค้ช Agile สมาชิกทีมพัฒนารายงานว่างานเสร็จสมบูรณ์ตั้งแต่เซสชั่นล่าสุด งานที่วางแผนไว้ก่อนเซสชันถัดไปและตัวบล็อกใด ๆ บล็อกเกอร์ที่ระบุถูกล้างโดยโค้ช Agile และผู้จัดการการจัดส่ง Stand-Up เป็นฟอรัมที่ยอดเยี่ยมสำหรับการประสานงานทั่วทั้งทีม
Backlog Grooming - วันจันทร์ PM ของเราได้ตรวจสอบและจัดทำรายการค้างใหม่ โค้ชและผู้จัดการการจัดส่ง Agile สนับสนุนการตรวจสอบและยืนยันเรื่องราวของผู้ใช้ที่เห็นด้วยกับ "คำจำกัดความของทีมพร้อม" ของทีม
Sprint Review - เช้าวันอังคารทีมนำเสนอเรื่องราวผู้ใช้ที่เสร็จสมบูรณ์ใน Sprint ไปยัง PM เพื่อตรวจสอบและอนุมัติ เรื่องราวของผู้ใช้ที่ได้รับการอนุมัติสอดคล้องกับ "คำจำกัดความของการทำ" ของทีม
Sprint Retrospective - เช้าวันอังคารทีมสะท้อนให้เห็นว่าเครื่องมือกระบวนการและเพื่อนร่วมงานของพวกเขาดำเนินการกับ Sprint ที่เพิ่งเสร็จสิ้นเมื่อเร็ว ๆ นี้ สมาชิกในทีมแต่ละคนถูกขอให้ระบุลักษณะการปรับปรุงหนึ่งที่พวกเขาต้องการเห็นทีมเริ่มทำ หนึ่งพวกเขาต้องการให้ทีมหยุดทำและคนที่พวกเขาต้องการให้ทีมดำเนินการต่อ อำนวยความสะดวกโดยโค้ช Agile การเริ่มต้น/หยุด/ต่อไปที่ระบุได้ถูกรวมเข้าด้วยกันและขั้นตอนต่อไปที่กำหนดโดยทีม
Sprint Planning - บ่ายวันอังคารเซสชั่นหนึ่งชั่วโมงสำหรับ PM และทีมที่พูดคุยกันอย่างมีปฏิสัมพันธ์และตกลงกันในการรับน้ำหนักของ Sprint ครั้งต่อไป การปรับขนาดของรายการใน Sprint ได้รับการประสานงานโดยโค้ช Agile และผู้จัดการการจัดส่ง planitpoker.com ใช้สำหรับการประมาณเรื่องราว
ดูอัลบั้มภาพทีมของเราสำหรับตัวอย่างภาพของทีมและกระบวนการ Agile ของเราในการดำเนินการ
ด้วยการทำซ้ำแต่ละครั้งต้นแบบได้รับการจัดเรียงให้สอดคล้องกับวิสัยทัศน์ของ PM มากขึ้นเช่นเดียวกับความต้องการของผู้ใช้ของเรา แผนงานระดับสูงของเรารวมถึงเรื่องราวของผู้ใช้หลายเรื่องที่ท้ายที่สุดไม่ได้รวมอยู่ในต้นแบบการทำงาน สิ่งเหล่านี้รวมถึงการวิจัยสไปค์สำหรับแอปพลิเคชันไคลเอนต์ iOS ดั้งเดิมและฟังก์ชั่นการแจ้งเตือนแบบพุชแบบดั้งเดิม ในขณะที่ทั้งคู่ไม่ได้อยู่ในผลิตภัณฑ์ที่มีศักยภาพขั้นต่ำที่โพสต์ (MVP) แต่ก็รวมอยู่ในแบ็คล็อกผลิตภัณฑ์สิ่งประดิษฐ์สถาปัตยกรรมและซอร์สโค้ด GitHub
ตลอดกระบวนการทีมสามารถประสานงานและติดตามความคืบหน้าโดยใช้บอร์ดการต่อสู้ของเรา เราใช้ JIRA เพื่อติดตามเรื่องราวของผู้ใช้บนกระดานอิเล็กทรอนิกส์ (รวมถึงข้อบกพร่อง) และรักษาบอร์ดทางกายภาพในห้องทีม เราใช้การบรรจบกันสำหรับการแบ่งปันเอกสารและ HipChat เป็นเครื่องมือการทำงานร่วมกันของทีมของเรา ตัวชี้วัดถูกติดตามเพื่อให้ทีมเข้าใจว่าพวกเขากำลังทำอะไรและพื้นที่ที่มีศักยภาพสำหรับการปรับปรุงกระบวนการด้วยการวิ่งแต่ละครั้ง ตัวชี้วัดแสดงให้เห็นว่าทีมความเร็วในการพัฒนาของพวกเขา, งานในมืออาชีพและเปอร์เซ็นต์ของเรื่องราวที่ถูกนำไปใช้กับการวิ่งแต่ละครั้ง
สำหรับการตัดสินใจทางเทคโนโลยีทุกครั้งเราได้พิจารณาตัวเลือกที่เปิดกว้างซึ่งส่งผลให้สแต็คเป็นโอเพนซอร์ส เป้าหมายเทคโนโลยีของเราคือเว็บแอปพลิเคชันที่ทันสมัยบนเบราว์เซอร์ แต่เรายังตรวจสอบความเป็นไปได้ของแอพมือถือดั้งเดิมบน iOS
รูปที่ 2 - สแต็คเทคโนโลยีของเรา 
จากมุมมอง DevOps:
เราทดสอบและปรับใช้ต้นแบบในโครงสร้างพื้นฐาน Azure ของ Microsoft เป็นโซลูชันบริการ (IAAS) เราใช้โซลูชันการตรวจสอบของ Azure สำหรับการตรวจสอบโครงสร้างพื้นฐานอย่างต่อเนื่องรวมถึงเครือข่ายและที่ระลึกใหม่สำหรับการตรวจสอบประสิทธิภาพการใช้งานอย่างต่อเนื่อง เราใช้ข้อมูลตัวบ่งชี้ประสิทธิภาพหลัก (KPI) เพื่อปรับแต่งโซลูชันและแอปพลิเคชันโครงสร้างพื้นฐานของเรา
โซลูชันของเราใช้ GitHub เพื่อใช้เอกสารรหัสและการทดสอบหน่วยในที่เก็บ GitHub สาธารณะของเรา โครงสร้าง GitHub ของเรามีสาขาหลักและการรวมสาขารวมถึงสาขาคุณสมบัติ การพัฒนาเรื่องราวของแต่ละบุคคลได้ทำในสาขาฟีเจอร์ในสภาพแวดล้อมท้องถิ่น ก่อนที่จะตรวจสอบรหัสในนักพัฒนาได้ออกคำขอดึงเพื่อทบทวนการตรวจสอบรหัส เมื่อการตรวจสอบรหัสได้รับการอนุมัติรหัสจะถูกรวมเข้ากับสาขาการรวมซึ่งเรียกกระบวนการรวมอย่างต่อเนื่อง
รูปที่ 3 แสดงมุมมองเครื่องมือและการย้ายรหัสระดับสูงจากการพัฒนาไปจนถึงการผลิตโดยใช้กระบวนการ CI/CD ของเรา
รูปที่ 3 - การรวมและการปรับใช้อย่างต่อเนื่อง (เครื่องมือ) 
เจนกินส์ดึงรหัสจาก GitHub สร้างแอปพลิเคชันและดำเนินการทดสอบหน่วย หากการทดสอบหน่วยทั้งหมดผ่านไป Docker จะสร้างภาพการแจกจ่าย เราใช้วิธีการซีดีที่มีการดูแลในสภาพแวดล้อมการทดสอบทุกคืนเพื่อหลีกเลี่ยงการแทรกแซงการทดสอบการทำงานอย่างต่อเนื่อง การปรับใช้เฉพาะกิจได้รับการสนับสนุนตามต้องการ เมื่อมีการปรับใช้งานบิลด์เพื่อทดสอบชุดทดสอบการทำงานของเรา (โดยใช้ซีลีเนียม) จะวิ่งโดยอัตโนมัติ
รูปที่ 4 - การรวมและการปรับใช้อย่างต่อเนื่อง (มุมมองกระบวนการ) 
นี่คือภาพรวมของขั้นตอนที่เราปฏิบัติตามในแนวทางของเรา:
. นักพัฒนาตั้งค่าสภาพแวดล้อมการพัฒนาท้องถิ่นโดยใช้ไฟล์ Docker เพื่อเลียนแบบสภาพแวดล้อมการดำเนินงานและสร้างสาขาคุณสมบัติจากสาขา GitHub Master (ขั้นตอนที่ 0)
ข. นักพัฒนาสร้างการทดสอบหน่วย (ขั้นตอนที่ 1) และเขียนซอร์สโค้ดที่เหมาะสม (ขั้นตอนที่ 2) เพื่อใช้เรื่องราว/คุณสมบัติของผู้ใช้
ค. ในการรวมการทดสอบหน่วยและซอร์สโค้ดนักพัฒนาซอฟต์แวร์ส่งคำขอดึง ทริกเกอร์การตรวจสอบรหัสโดยนักพัฒนาเพียร์; ผู้ตรวจสอบอนุมัติ/ ปฏิเสธการรวมเข้ากับสาขาการรวม; ในที่สุดนักพัฒนาซอฟต์แวร์แก้ไขข้อสังเกตการตรวจสอบรหัส เมื่อการตรวจสอบรหัสได้รับการอนุมัติสาขาฟีเจอร์จะถูกรวมเข้ากับสาขาการรวม (ขั้นตอนที่ 4)
d. ผู้ทดสอบสร้างสคริปต์การทำงานอัตโนมัติ (ขั้นตอนที่ 3) ซึ่งรวมอยู่ในสาขาการรวม (ขั้นตอนที่ 4)
ก. ในกำหนดการที่กำหนดไว้ล่วงหน้าเจนกินส์จะรวบรวมซอร์สโค้ดและการทดสอบหน่วยทั้งหมดจะดำเนินการโดยอัตโนมัติ (ขั้นตอนที่ 5)
f. หากการทดสอบหน่วยล้มเหลวการแจ้งเตือนจะถูกส่งเกี่ยวกับความล้มเหลวและผู้พัฒนาจะแก้ไขในสาขาคุณสมบัติผู้สื่อข่าว (ขั้นตอนที่ 15) ขั้นตอนที่ 4 และ 5 จะทำซ้ำจนกว่าการทดสอบหน่วยจะผ่าน
กรัม เมื่อหน่วยทดสอบผ่านแล้วเจนกินส์จะดำเนินการไฟล์ Docker เพื่อสร้างอิมเมจนักเทียบท่าสำหรับ UI และแบ็กเอนด์ (ขั้นตอนที่ 6)
ชม. Docker ผลักดันภาพไปยัง Azure Registry (ขั้นตอนที่ 7) จากนั้นนำไปใช้กับสภาพแวดล้อมการทดสอบที่การทดสอบการทำงานจะดำเนินการโดยอัตโนมัติ (ขั้นตอนที่ 8)
ฉัน. หากการทดสอบการทำงานล้มเหลวการแจ้งเตือนจะถูกส่ง (ขั้นตอนที่ 14) และนักพัฒนาแก้ไขปัญหา (ขั้นตอนที่ 15) ขั้นตอนที่ 4, 5, 6, 7 และ 8 ถูกทำซ้ำจนกว่าการทดสอบการทำงานจะผ่าน
j. เมื่อการทดสอบการทำงานสำเร็จจะมีการส่งการแจ้งเตือนเกี่ยวกับการดำเนินการทดสอบที่ประสบความสำเร็จ (ขั้นตอนที่ 9)
ก. QA ทำการทดสอบแบบ Ad-Hoc/Manual หากสิ่งเหล่านี้ล้มเหลวนักพัฒนาจะได้รับแจ้งให้แก้ไขปัญหา (ขั้นตอนที่ 15) ขั้นตอนที่ 4, 5, 6, 7, 8, 9 และ 10 จะทำซ้ำจนกว่าการทดสอบเฉพาะกิจจะผ่าน
ล. เมื่อข้อผิดพลาดได้รับการแก้ไขสาขาการรวมจะถูกรวมเข้ากับแท็กการผลิตในสาขาหลัก (ขั้นตอนที่ 11)
ม. ในที่สุดรูปภาพที่สร้างขึ้นสำหรับการทดสอบจะถูกนำไปใช้กับสภาพแวดล้อมการผลิต (ขั้นตอนที่ 12)
ซอร์สโค้ดของเรามีโครงสร้างเพื่อติดตามสถาปัตยกรรมแบบกระจายของเราและซอฟต์แวร์ที่ใช้ในการใช้งาน ส่วนหน้าถูกเก็บไว้ในโฟลเดอร์เชิงมุมและแบ็กเอนด์ในโฟลเดอร์ Dropwizard นอกจากนี้เรายังมีโฟลเดอร์สำหรับการทดสอบการทำงานอัตโนมัติในโฟลเดอร์ซีลีเนียม
UI ถูกสร้างขึ้นโดยใช้ AngularJs ภายในโฟลเดอร์เชิงมุมโฟลเดอร์แอพจะรวมโฟลเดอร์ย่อยสำหรับรูปภาพภาษาสไตล์ชีทสคริปต์สคริปต์และมุมมอง โฟลเดอร์สคริปต์มีคอนโทรลเลอร์โรงงานและบริการ โฟลเดอร์คอนโทรลเลอร์จะเป็นโฮสต์ไฟล์ JavaScript ในขณะที่โฟลเดอร์ View มีไฟล์ HTML การทดสอบหน่วยจะถูกเก็บแยกต่างหากจากรหัสในโฟลเดอร์ทดสอบ
ส่วนหน้าสื่อสารกับแบ็กเอนด์โดยใช้ RESTFUL API รหัสส่วนหน้าเรียกใช้บริการอยู่ในโฟลเดอร์ย่อยบริการภายใต้โฟลเดอร์สคริปต์
แอปพลิเคชันแบ็กเอนด์ใช้ตรรกะทางธุรกิจสื่อสารกับบริการภายนอกส่งการแจ้งเตือนและโต้ตอบกับฐานข้อมูล แบ็กเอนด์ถูกนำมาใช้โดยใช้ Dropwizard ซึ่งให้กรอบ Java พร้อมการสนับสนุน REST และ Junit ตรรกะทางธุรกิจและจุดสิ้นสุดอยู่ในโฟลเดอร์ทรัพยากรและการใช้บริการอยู่ในโฟลเดอร์บริการ
แอปพลิเคชันยังใช้เครื่องห่อ API ภายนอก (นำไปใช้ที่นี่) เพื่อดึงข้อมูลจากแหล่งข้อมูลภายนอก
การทดสอบหน่วยอยู่ในโฟลเดอร์ทดสอบ
แอปพลิเคชันสื่อสารกับฐานข้อมูลเชิงสัมพันธ์ (MySQL) โดยใช้ไฮเบอร์เนต เราใช้การตรวจสอบการตรวจสอบความถูกต้องของข้อมูล JAXB สำหรับการตรวจสอบความถูกต้องของข้อมูล วัตถุการเข้าถึงข้อมูลและวัตถุโมเดลอยู่ในโฟลเดอร์ DAO
. มอบหมายผู้นำหนึ่ง (1) คนและให้อำนาจและความรับผิดชอบของบุคคลนั้นและถือว่าบุคคลนั้นรับผิดชอบต่อคุณภาพของต้นแบบที่ส่งมา
ในระหว่างการประเมิน RFI CGI เลือกผู้จัดการผลิตภัณฑ์ (PM) ตามประสบการณ์ด้านเทคนิคและการจัดการของเขา CGI ให้อำนาจการตัดสินใจขั้นสุดท้ายของ PM เกี่ยวกับการออกแบบและพัฒนาต้นแบบ
ข. ประกอบทีมสหสาขาวิชาชีพและทีมงานร่วมกันซึ่งรวมถึงอย่างน้อยห้า (5) หมวดหมู่แรงงานตามที่ระบุไว้ในเอกสารแนบ B: PQVP DS-AD หมวดหมู่คำอธิบาย
ภายใต้การนำของ PM CGI ได้รวบรวมทีมสหสาขาวิชาชีพด้วยความสามารถทางเทคนิคและความคล่องตัวต่างๆ
ทีมของเรา:
ค. เข้าใจสิ่งที่ผู้คนต้องการโดยรวมถึงผู้คนในการพัฒนาต้นแบบและกระบวนการออกแบบ
CGI ปฏิบัติตามวิธีการที่ผู้ใช้เป็นศูนย์กลางในการออกแบบและพัฒนาต้นแบบของเรา นักออกแบบ UX/UI ของเรามีส่วนร่วมกับผู้ใช้ แต่เนิ่นๆผ่านการใช้การสัมภาษณ์ Persona และการสำรวจ ผลการสัมภาษณ์กลายเป็น Wireflows อย่างรวดเร็ว Wireflows ได้รับการปรับปรุงจากการสำรวจผู้ใช้รวมถึงการทดสอบการใช้งานกับผู้ใช้ของเรา Wireflows เป็นวิธีที่รวดเร็วและมองเห็นได้ในการสื่อสารกับนักพัฒนาให้กับนักพัฒนาที่ต้องการต้นแบบที่ต้องการและรู้สึกว่าการพัฒนาสามารถเริ่มต้นได้เมื่อ PM อนุมัติเรื่องราวเริ่มต้น
เราใช้เทคนิคการออกแบบและเครื่องมือรวมถึงการสัมภาษณ์ตัวตนการพัฒนา wireflow การทดสอบการใช้งานและ Lean UX เพื่อพัฒนา UI ของเรา เพื่อสนับสนุนอินเทอร์เฟซที่ตอบสนองต่อเบราว์เซอร์เราใช้ประโยชน์จากแนวทางจาก US Web Design (USWD) สำหรับมาตรฐานเว็บที่ทันสมัยและ AngularJs การใช้มาตรฐานเหล่านี้พร้อมกับอินพุตจากผู้ใช้ทำให้เราสามารถสร้างต้นแบบที่ง่ายและใช้งานง่ายในการนำทางและใช้งาน นอกจากนี้เรายังทดสอบการปฏิบัติตาม ADA 508 และ WCAG 2.0 โดยใช้เครื่องมืออัตโนมัติเพื่อทดสอบการสนับสนุนผู้อ่านแบบปรับตัวและตัวเลือกการมองเห็นต่ำอื่น ๆ
d. ใช้อย่างน้อยสาม (3) เทคนิค“ การออกแบบผู้ใช้เป็นศูนย์กลาง” และ/หรือเครื่องมือ
เราใช้การสัมภาษณ์ Personas, Wireflows และการทดสอบการใช้งานเป็นเครื่องมือหลักของเราในการพัฒนาการออกแบบสำหรับต้นแบบของเราที่มุ่งเน้นความต้องการและความต้องการของผู้ใช้ของเรา
ก. ใช้ GitHub เพื่อเอกสารรหัส
สามารถดูได้ใน GitHub: https://github.com/cgi-zahid/cgi-poc
f. ใช้ Swagger เพื่อจัดทำเอกสาร API RESTFUL และให้ลิงก์ไปยัง Swagger API;
การสื่อสารทั้งหมดกับระดับกลางได้ทำโดยใช้ REST API Middle Tier เปิดเผยส่วนที่เหลือโดยใช้ JAX RX และมีการบันทึกไว้ใน Swagger
กรัม ปฏิบัติตามมาตรา 508 ของพระราชบัญญัติคนพิการชาวอเมริกันและ WCAG 2.0;
เป็นส่วนหนึ่งของการทดสอบการใช้งานของเราเราได้ทดสอบการปฏิบัติตาม 508 และ WCAG 2.0 เราใช้การทดสอบอัตโนมัติเพื่อทดสอบความสามารถในการอ่านและการมองเห็นต่ำ เราแก้ไขข้อผิดพลาดซึ่งเป็นส่วนหนึ่งของกระบวนการค้างของเรา ผลการทดสอบอื่น ๆ ได้รับการประเมินเพื่อพิจารณาว่าจะเพิ่มใน backlog และสิ่งที่ไม่ได้ใช้กับต้นแบบของเรา
เราใช้ ACTF Adesigner สำหรับการทดสอบ 508 ของเรา
ชม. สร้างหรือใช้คู่มือสไตล์การออกแบบและ/หรือไลบรารีรูปแบบ
UX/UI สร้างคู่มือสไตล์โดยใช้มาตรฐานการออกแบบเว็บของสหรัฐอเมริกา โทนสีของเราได้รับการคัดเลือกตามสีของรัฐแคลิฟอร์เนียและได้รับการอนุมัติจากความคิดเห็นของผู้ใช้ การใช้มาตรฐานการออกแบบเว็บของสหรัฐอเมริกาพร้อมกับอินพุตจากผู้ใช้ทำให้เราสามารถสร้างต้นแบบซึ่งง่ายและใช้งานง่ายในการนำทางและใช้งาน
ฉัน. ทำการทดสอบการใช้งานกับผู้คน
เป็นส่วนหนึ่งของวิธีการเป็นศูนย์กลางของผู้ใช้เรารวมการทดสอบการใช้งานไว้ในกระบวนการของเรา การทดสอบการใช้งานได้ดำเนินการผ่านการสำรวจผู้ใช้ใน wireframes ของเรารวมถึงข้อเสนอแนะจากผู้ใช้ที่ทดสอบต้นแบบของเราตลอดการวิ่งของเรา ข้อเสนอแนะจากการทดสอบการใช้งานได้รับการประเมินโดยนักออกแบบ PM และ UX เพื่อกำหนดสิ่งที่จะรวมไว้ใน backlog ตามทิศทางของ PM เรื่องราวใหม่ถูกสร้างขึ้นจัดลำดับความสำคัญและวางไว้ในงานในมือของเรา
j. ใช้วิธีการวนซ้ำที่ข้อเสนอแนะแจ้งงานที่ตามมาหรือรุ่นของต้นแบบ;
ภายในการวิ่งแต่ละครั้งอินพุตที่ได้รับจากผู้จัดการผลิตภัณฑ์ผู้ทดสอบการใช้งานและข้อบกพร่องที่ระบุในระหว่างการทดสอบได้รับการประเมินจัดลำดับความสำคัญและรวมอยู่ใน backlog เป็นส่วนหนึ่งของวิธีการวนซ้ำของเรา ด้วยการสาธิตแต่ละครั้งต้นแบบนั้นสอดคล้องกับวิสัยทัศน์ของ PM มากขึ้นเรื่อย ๆ รวมถึงความต้องการของผู้ใช้ของเรา
ก. สร้างต้นแบบที่ทำงานบนอุปกรณ์หลายเครื่องและนำเสนอการออกแบบที่ตอบสนองได้
รหัสของเราได้รับการทดสอบโดยใช้อุปกรณ์หลายตัวและทำงานกับเว็บเบราว์เซอร์หลายตัว นอกจากนี้รหัสของเราได้รับการทดสอบโดยใช้อุปกรณ์ Apple และ Android
เราทดสอบ:
ล. ใช้เทคโนโลยีอย่างน้อยห้า (5) เทคโนโลยีที่ทันสมัยและโอเพ่นซอร์สโดยไม่คำนึงถึงชั้นสถาปัตยกรรม (ส่วนหน้า, แบ็กเอนด์ ฯลฯ );
เราใช้เทคโนโลยีที่ทันสมัยและโอเพ่นซอร์สหก (6) รายการต่อไปนี้:
รายการเทคโนโลยีทั้งหมดของเรามีให้: รายการเทคโนโลยี แถวที่เน้นสีเขียวบนสเปรดชีตเป็นเทคโนโลยีที่ทันสมัยและโอเพ่นซอร์ส
ม. ปรับใช้ต้นแบบบนโครงสร้างพื้นฐานเป็นบริการ (IAAS) หรือแพลตฟอร์มเป็นผู้ให้บริการ (PAAS) และระบุว่าผู้ให้บริการที่พวกเขาใช้;
เราใช้ Azure เป็นผู้ให้บริการ IaaS ของเรา
n. การทดสอบหน่วยอัตโนมัติที่พัฒนาขึ้นสำหรับรหัสของพวกเขา;
ก่อนที่จะตรวจสอบรหัสลงในนักพัฒนาสาขาฟีเจอร์ให้ทำคำขอดึงเพื่อทริกเกอร์การตรวจสอบรหัส เมื่อการตรวจสอบรหัสได้รับการอนุมัติรหัสจะถูกรวมเข้ากับสาขาการรวมซึ่งก่อให้เกิดกระบวนการปรับใช้อย่างต่อเนื่อง
o. การตั้งค่าหรือใช้ระบบการรวมอย่างต่อเนื่องเพื่อทำให้การทำงานของการทดสอบโดยอัตโนมัติและปรับใช้รหัสของพวกเขาอย่างต่อเนื่องกับผู้ให้บริการ IAAS หรือ PAAS ของพวกเขา
เราใช้เจนกินส์สำหรับการรวมอย่างต่อเนื่อง มันคว้ารหัสจาก GitHub และรวบรวมและดำเนินการทดสอบ หากรหัสผ่านการทดสอบแล้ว Docker จะสร้างภาพ ภาพจะถูกนำไปใช้กับสภาพแวดล้อมการทดสอบระบบซึ่งทำการทดสอบการทำงานจากจุดสิ้นสุดโดยใช้ซีลีเนียม
หน้า การตั้งค่าหรือการจัดการการกำหนดค่าที่ใช้
Azure Container Registries ถูกใช้เพื่อจัดเก็บและจัดการภาพนักเทียบท่าของเราทำให้เราสามารถจัดการการกำหนดค่าได้
ถาม การตั้งค่าหรือใช้การตรวจสอบอย่างต่อเนื่อง
Azure และใหม่ของที่ระลึกถูกนำมาใช้เพื่อตรวจสอบสุขภาพของสิ่งแวดล้อมอย่างต่อเนื่องและแอปพลิเคชัน
R. ปรับใช้ซอฟต์แวร์ของพวกเขาในคอนเทนเนอร์โอเพ่นซอร์สเช่น Docker (เช่นใช้การจำลองเสมือนจริงระดับระบบปฏิบัติการ)
เราปรับใช้ซอฟต์แวร์ของเราโดยใช้ Docker
s. จัดทำเอกสารให้เพียงพอในการติดตั้งและเรียกใช้ต้นแบบบนเครื่องอื่น
ด้านล่างนี้เป็นลิงค์ไปยังคำแนะนำการติดตั้งของเรา
คำแนะนำ
t. ต้นแบบและแพลตฟอร์มพื้นฐานที่ใช้ในการสร้างและเรียกใช้ต้นแบบได้รับใบอนุญาตอย่างเปิดเผยและไม่มีค่าใช้จ่าย
เราใช้แพลตฟอร์มที่ได้รับใบอนุญาตอย่างเปิดเผยและไม่มีค่าใช้จ่าย
รายการเครื่องมือ
กระบวนการของเราสำหรับการออกแบบและพัฒนาต้นแบบของเราตามมาและเป็นไปตามมาตรฐานหลายอย่างที่ระบุไว้ใน Playbook Services Digital Services ของสหรัฐอเมริกา เราจัดทำเอกสารโดยละเอียดเกี่ยวกับ GitHub ซึ่งเชื่อมโยงกับหลักฐานของเรารวมถึงการตอบสนองของเราต่อแต่ละรายการ
การตอบสนอง playbook บริการดิจิทัลของเรา
