ธนาคารในอนาคต

ธนาคารแบบดั้งเดิมกำลังจะเปลี่ยนไปในอนาคต เมื่อเทคโนโลยีก้าวล้ำขึ้น จนเปลี่ยนพฤติกรรมผู้บริโภคไป ธนาคารก็ย่อมปรับตัวตาม โดยจะปรับไปเป็น Financial Service ที่ให้บริการด้านการเงินทุกรูปแบบ พนักงานสาขาจะปรับไปเป็นพนักงานให้บริการลูกค้าไปเป็นที่ปรึกษาด้านการเงินให้แก่ลูกค้า แต่อย่างไรเสียไอทีก็ยังมีข้อจำกัด มีหลายสิ่งที่คนยังต้องการมีปฏิสัมพันธ์กับคนด้วยกัน…

4-mobile-learning-benefits-banking-financial-services-industryเครดิตภาพ: elearningindustry.com

พนักงานจะได้รับการอบรมให้เป็นในแนวทางกึ่งๆ sales + consultant + customer service/support สมัยนี้อาจเรียกว่า sales specialist, financial solution specialist ฯลฯ ซึ่งมีหน้าที่รับผิดชอบกว้างขึ้น (ต้องมีทักษะหลายด้านขึ้น) แต่ไม่ลึก (ไม่ต้องรู้ลึก/ศึกษาลึก) เป็นเสมือน agent (ตัวแทน) ก่อนรายละเอียดลูกค้าไหลไปถึงระบบไอทีที่ทำงานอัตโนมัติซึ่งเร็วกว่าแม่นยำกว่าและฉลาดกว่ามนุษย์ในหลายด้าน รวมถึงประหยัดต้นทุนกว่า

อ่านเพิ่มเติม

ความสามารถและหน้าที่ Architect ด้าน IT/Software/Solution

หลายปีที่ผ่านมามีคนถามบ่อยครั้งมากเกี่ยวกับการพัฒนาความสามารถด้าน software architecture ซึ่งรวมไปถึงด้าน IT architecture และ solution architecture งานทั้ง 3 ด้านนี้คล้ายคลึงกัน ต่างกันที่ขอบเขตและระดับความลึกของงาน นอกจากนี้ยังได้ไปบรรยายและเป็นที่ปรึกษาให้กับหลายองค์กร จึงได้รายละเอียดที่เคยรวบรวมมาเอามาเล่าสู่กันครับ…

Solution Architect

ความสามารถ (ความรู้ + ทักษะ + คุณลักษณะ) ของ Architect ด้าน IT (IT Architect) หรือ ด้าน Software (Software Architect) หรือ ด้าน Solution (Solution Architect) มีมากมายมหาศาลครับ เพราะงานด้าน architecture ต้องรู้กว้าง มีความสามารถหลากหลาย ดังนั้นอย่าเพิ่งตกใจกันครับ ส่วนจะรู้ลึกไปด้านไหนก็ขึ้นกับความสนใจส่วนตัวและขึ้นกับ domain ของงานที่ทำครับ

สำหรับ architect นั้นมี 2 แบบใหญ่ๆ คือ architect แนวกว้าง (cross domain architect) หรือ architect แนวนอน ที่ต้องรู้กว้าง เก่งแบบกว้างๆ ไปทำระบบอะไรก็ได้ไม่ได้ชำนาญใน domain ใด domain หนึ่ง ไปทำงานในองค์กรในอุตสาหกรรมหรือธุรกิจประเภทไหนก็ได้ หรือระบบหรือเทคโนโลยีอะไรก็ได้ (ผมเองก็เป็น architect ประเภทนี้ครับ เพราะผมเป็นฟรีแลนซ์ ทำงานอิสระ เจอลูกค้าแบบไหนก็ได้) ส่วน architect แบบที่สองคือ architect แนวลึก (domain architect) หรือ architect แนวตั้ง ที่ต้องรู้ลึกใน domain ใด domain หนึ่ง เช่น ชำนาญด้านระบบ banking ชำนาญด้านเทคโนโลยี .NET ชำนาญระบบประเภท web application เป็นต้น สำหรับ architect ประเภทนี้ถ้าเลือกสนใจทำ domain ใดแล้ว การจะมาเปลี่ยนไป domain อื่นในภายหลัง เช่น ย้ายงาน อาจเหนื่อยหน่อย แต่ถ้าเป็นคนที่รักการเรียนรู้และปรับตัวง่ายก็ไม่น่ากังวล

คราวนี้มาดูกันครับ ว่าความสามารถและขอบเขตของ architect ด้าน IT/Software/Soltuion มีอะไรกันบ้าง…

ทักษะ และ หน้าที่

  • Analyze, design and maintain IT solution
  • Define architecture landscape
  • Analyze, design and maintain solution architecture, focus on structure and interoperation of business, data, application, service, technology, infrastructure
  • Listen to and make understanding all key stakeholder’s aspect
  • Define and clarify constraints, concerns, business goals, system features, use cases, quality attributes, mechanisms
  • Find win-win solution for all key stakeholders
  • Collaborate with a variety of stakeholders (product development, operation, infrastructure, development, vendor, etc.)
  • Define architecture principles to shape the implementation
  • DELIVER SOLUTION!

ความรู้ด้านไอที

  • Object-Oriented Analysis and Design
  • UML (Unified Modeling Language)
  • Design principles
  • Software development principles
  • Non-Functional Requirements, Quality Attributes
  • Enterprise architecture, Software architecture
  • Solution analysis, design and management
  • Software process: CMMI, Agile
  • Design Patterns, Architectural Patterns
  • IT security
  • Business technology

ความรู้และทักษะด้านอื่น (สำคัญมาก เป็น soft skill และ เป็นตัวชี้วัดสำคัญ)

  • Communication
  • Business thinking
  • Transform idea to picture by drawing/modeling
  • Feasibility study and proof-of-concept
  • Documentation
  • Consulting and coaching
  • Strategy
  • Risk and change management
  • Political and social issues handling

ArchitectingContext

อ่านเพิ่มเติม

เกริ่นเบาๆ กับ Stress Test

การทำ Stress Test กับระบบไอที เป็นสิ่งที่องค์กรขนาดใหญ่ในไทยควรให้ความสนใจกันให้มากขึ้นและเริ่มทำกันอย่างจริงจังมากขึ้น เนื่องจากหลายปีมานี้ระบบไอทีสำคัญๆ ในองค์กรขนาดใหญ่เกิดปัญหาจนเป็นข่าวบ่อยครั้ง อาทิ ระบบล่ม ระบบโดนแฮ็ก ฯ

Stress Test คือ การทดสอบความแข็งแกร่ง (robustness) ของระบบไอที ว่ามีความอดทน อึด ทนทาน (fault tolerance) แค่ไหน การทดสอบทำด้วยการจำลองสถานการณ์การทดสอบ (test scenario) ที่เลวร้าย ‘มากๆ’ หลากหลายรูปแบบ แล้วทดสอบระบบว่า ‘มันยังไหว’ อยู่ไหม ยังทำงานได้ดีอยู่หรือไม่ ช้าไหม ล่มไหม เกิดช่องโหว่ด้านความปลอดภัยไหม นอกจากนี้ในแง่ระบบไอทีควรออกแบบสถานการณ์ทดสอบแบบ ‘ปัญญาอ่อน’ ไว้ด้วย เพราะเหตุการณ์ปัญญาอ่อนง่ายๆ เช่น ความสะเพร่าโดยคนก็อาจก่อให้เกิดปัญหาใหญ่ต่อระบบได้

การทำ Stress Test ก็เหมือนการตรวจสุขภาพแบบ ‘จัดเต็ม’ ตรวจทุกอย่างในร่างกาย

Stress Test

ที่พบเห็นทั่วไปในหลายองค์กรที่มักทำกันคือ การทำ Load Test ซึ่งก็เป็นแนวปฏิบัติหนึ่งในการทำ Stress Test เพียงแต่เน้นไปที่ดูความสามารถในรองรับ Load ซึ่งเป็นหัวใจสำคัญของการทำงานของระบบไอที เป็นการดูคุณภาพด้าน Performance ของระบบไอที และยังใช้ประเมินระดับเสถียรภาพของระบบ (System Stability) เพื่อเอาไว้เซ็ตบรรทัดฐาน (Baseline) เพื่อใช้กำหนดขอบเขตในการติดตามและควบคุมคุณภาพ เช่นอาจอาศัยการดูจากการแกว่งตัวของช่วงคุณภาพในช่วงเวลาและสถานการณ์ต่างๆ

อ่านเพิ่มเติม

หนทางค้นพบโซลูชั่น

ปัญหาเกิดจากภายในใจเรา วิธีแก้ปัญหาก็เกิดจากภายในใจเรา

คนจำนวนมากใช้ ‘ตา’ มองออกไปข้างนอก แต่ลืมหลับตามองเข้ามาในตัวตน

พระพุทธเจ้ากล่าวไว้ว่าปัญญาเกิดได้ 3 ระดับ

1. สุตมยปัญญา คือ ปัญญาที่เกิดจากการอ่านและฟัง

2. จินตามยปัญญา คือ ปัญญาที่เกิดจากการคิดตาม

3. ภาวนามยปัญญา คือ ปัญญาที่เกิดจากการคิดวิเคราะห์สังเคราะห์ -> คือการพิจารณาข้อดี ข้อเสีย จำแนกแยกแยะประเด็นย่อยๆ คิดอย่างลึกซึ้งลงไปจนพบแก่นของประเด็นหรือปัญหา ใคร่ครวญ พิจารณา จนเข้าใจและค้นพบวิธีแก้ปัญหาแบบฉับพลัน (ภาวะตระหนักรู้ หรือ ที่เราชอบเรียกกันว่าช่วง ‘ปิ๊ง’ นั่นล่ะ ไอเดียมันเกิดขึ้นแบบฉับพลัน)

ภาวนามยปัญญาอาจใช้เวลาเนิ่นนานกว่าจะพบวิธีแก้ปัญหา แต่ก็อาจใช้เวลาสั้นเพียงเสี้ยววินาทีได้

นักวิทยาศาสตร์ระดับโลก (เช่นไอน์สไตน์) หรือศิลปินชื่อดัง (เช่นไมเคิล แองเจโล) ก็เคยใช้ภาวนามยปัญญาตอนค้นพบทฤษฎีหรือสร้างสรรค์ผลงานชิ้นเยี่ยม แต่ฝรั่งเขาไม่รู้จักการเกิดปัญญา 3 ระดับในทางพุทธหรอก เพราะเรื่องเหล่านี้มันเป็นเรื่อง ‘ธรรมชาติ’ ไม่ใช่เรื่องศาสนา

ธรรมชาติมอบสิ่งมหัศจรรย์ให้กับมนุษย์ แต่มนุษย์สมัยนี้ลืมที่จะใช้ศักยภาพเหล่านั้น

ป.ล. ก่อนจะใช้ภาวนามยปัญญา ต้องปรับทัศนคติให้ดีก่อน เพราะทัศนคติแย่ๆ จะเป็นกำแพงกั้นการเกิดปัญญาและการค้นพบวิธีแก้ปัญหา

อธิบาย Functional Requirement สไตล์ User Story

ในกระบวนการพัฒนาซอฟต์แวร์แบบ Agile นิยมทำเอกสารแบบสั้นกระชับอธิบายมุ่งเน้นจุดสำคัญ มากกว่าการบรรยายยืดยาวและการใช้เทมเพลตเอกสารที่เป็นทางการมีพิธีรีตรองมากมาย ในการอธิบาย functional requirement ในแบบ Agile มีรูปแบบที่เป็นที่นิยมกันคือ ‘User Story‘ เป็นคำง่ายๆ ตรงไปตรงมา นั่นก็คือ การอธิบายเรื่องราวของผู้ใช้ (ที่เข้ามาปฏิสัมพันธ์กับระบบ) เป็นคำที่ผมชอบมาก เพราะตรงไปตรงมาชัดเจน

การอธิบาย functional requirement คือ การอธิบายรายละเอียดที่ผู้ใช้หรือไคลเอ็นต์เข้ามาปฏิสัมพันธ์กับระบบ ซึ่งก็คือการเข้ามาใช้งานระบบนั่นเอง ถ้าไคลเอ็นต์เป็นคนมักเรียกว่า ‘ผู้ใช้’ (user) เข้ามาเรียกใช้ ‘ฟังก์ชั่น’ ของระบบ ถ้าไคลเอ็นต์เป็นอุปกรณ์ (device) หรือระบบภายนอก (external system) สมัยนี้มักเรียกว่า ‘ไคลเอ็นต์’ (หรือระบุชื่ออุปกรณ์หรือชื่อระบบไปเลย) เข้ามาเรียกใช้ ‘เซอร์วิส’ (หรือ API) ของระบบ

อย่าลืมว่าในช่วงที่อธิบายความต้องการนั้นเป็นช่วงของงาน requirement ยังไม่เข้าสู่ช่วงวิเคราะห์และออกแบบระบบ ดังนั้นงาน requirement คืองานที่จะต้องจดจ่ออยู่กับปัญหาและความต้องการ ยังไม่ข้ามไปสนใจเรื่องโซลูชั่นเท่าใดนัก การอธิบายความต้องการจึง ‘ยัง‘ ไม่ควรอธิบายเกี่ยวกับโซลูชั่น ซึ่งหมายถึงไม่ควรอธิบายในมุมมองว่าระบบต้องทำอะไร ระบบทำอะไรได้บ้าง ระบบมีฟังก์ชั่นอะไร ซึ่งเป็นสิ่งที่คนจำนวนมากชอบทำกัน แสดงว่าใจร้อนรีบไปคิดถึงระบบ สาเหตุหนึ่งเพราะนักไอทีมักมีกระบวนทัศน์แบบ ‘ในออกนอก’ (inside-out) แต่สำหรับงาน requirement ผู้รับผิดชอบด้านนี้ควรคิดแบบ ‘นอกเข้าใน’ (outside-in) คล้ายกับนักการตลาด ที่ต้องทำความเข้าใจตลาดและลูกค้าก่อน แล้วค่อยมาคิดถึงผลิตภัณฑ์ ฉะนั้นการอธิบายความต้องการโดยเฉพาะความต้องการประเภท functional requirement จึงควรอธิบายในมุมมอง ‘เรื่องราวของผู้ใช้ที่เข้ามาปฏิสัมพันธ์กับระบบ

User Story เป็นคำที่ชัดเจน ตอกย้ำว่าให้อธิบายในมุมมองจากผู้ใช้เข้ามาที่ระบบ (outside-in) อธิบายความต้องการของผู้ใช้ ความคาดหวังของผู้ใช้ โดยอธิบายด้วยภาษาที่เรียบง่ายอ่านเข้าใจง่าย ไม่ใช้ศัพท์เทคนิคยุ่งยาก

อ่านเพิ่มเติม

Product Design

 

 

ProductDesign

ตัวอย่าง Product Design, source: http://ernsteverything.blogspot.com

สมัยเรียน ม.ปลาย ช่วงปิดเทอมผมเคยขอที่บ้านไปเรียน ‘Architectural Design’ เพราะขี้เกียจอยู่ช่วยงานที่บ้าน😀 เป็นการเรียนด้านศิลปะ เพราะชอบเป็นการส่วนตัว และเพื่อเตรียมสอบเอนทรานซ์เข้าคณะสถาปัตยกรรม (ที่สุดท้ายเอนฯ ไม่ติด อดออกแบบบ้าน แต่สุดท้ายได้มาออกแบบซอฟต์แวร์แทน😀 ) ครูที่สอนสอนหลายหัวข้อมาก ผมจำได้ดีว่ามีหัวข้อหนึ่งที่ผมชอบมากแต่ทำไม่ได้ดีเท่าไหร่ คือ หัวข้อ ‘Product Design’ หรือ การออกแบบผลิตภัณฑ์ ด้วยข้อจำกัดในเรื่องเวลาและพื้นที่นำเสนอ และการระเบิดจินตนาการให้สุดโต่ง ซึ่งประเด็นหลังนี่ล่ะที่ผมทำไม่ได้ดี เพราะสมัยนั้นความคิดและความกล้าผมมีกรอบมากไปหน่อย แรงระเบิดจึงไม่มีพลังนัก ต้องใช้เวลากว่า 10 ปีหลังจากนั้น ผมจึงกล้าฉีกทุกกรอบและมีความคิดขบถสุดขีด ผมจำความรู้ด้าน Product Design ได้ดี และนำมาใช้ตลอดในทุกงานของผม ผมมักเริ่มออกแบบซอฟต์แวร์ด้วยแนวคิด Product Design เสมอ เพราะมันช่วยให้ได้ภาพรวมออกมาเร็ว

อ่านเพิ่มเติม

Functional Requirement หรือ Use Case

Functional Requirement หรือ ในทางการพัฒนาซอฟต์แวร์แบบ Object-Orientation เรียกว่า Use Case คือ ความต้องการที่เกี่ยวกับการทำงานของระบบ ว่าระบบต้องทำอะไรได้บ้างเพื่อสนับสนุนการใช้งานโดยไคลเอ็นต์ เป็นการทำงานที่ไคลเอ็นต์ใช้ได้โดยตรง  หากไคลเอ็นต์เป็นระบบภายนอกสมัยนี้นิยมเรียกว่า ‘เซอร์วิส’ เป็นการเข้ามาเรียกเซอร์วิส

ทีมพัฒนาระบบส่วนมากมักชอบระบุฟังก์ชั่นกันก่อน แล้วค่อยมาระบุไคลเอ็นต์หรือผู้ใช้ภายหลัง จริงๆ ควรระบุไคลเอ็นต์ก่อน แล้วค่อยระบุฟังก์ชั่นภายหลัง เพราะนักไอทีมีวิธีคิดแบบ ‘ในออกนอก’ (inside-out) แต่งาน requirement ควรคิดแบบ ‘นอกเข้าใน’ (outside-in) เหมือนการทำธุรกิจ ต้องมองตลาดก่อน เข้าใจลูกค้าก่อน แล้วค่อยมาดูว่าออกแบบและพัฒนาผลิตภัณฑ์อะไรไปขายลูกค้า นักไอทีชอบคิดถึงระบบก่อน แล้วก็นั่งเทียนฝันถึงฟังก์ชั่น คิดแต่ว่าระบบต้องมีฟังก์ชั่นอะไรบ้าง

 

*ไม่ใช่ทุกสิ่งที่ระบบทำแล้วเหมารวมเรียกว่า ‘ฟังก์ชั่น’ จำง่ายๆ แบบนี้ละกันครับ ฟังก์ชั่นหรือเซอร์วิส คือ การทำงานที่ไคลเอ็นต์เข้ามาเรียกใช้ได้โดยตรง ส่วนการทำงานภายในระบบที่ไคลเอ็นต์เรียกใช้ไม่ได้ (เช่น transaction management, data access, โมดูลคำนวณภาษี) เรียกว่า ‘กลไกการทำงานภายใน’ ซึ่งไม่ใช่ฟังก์ชั่นหรือเซอร์วิส โดยเจ้ากลไกการทำงานภายในนี้ เรียกอีกอย่างได้ว่า ‘กลไกทางสถาปัตยกรรม’ (architectural mechanism) หรือคือส่วนการทำงานที่เป็น ‘non-function’ นั่นเอง (ดู Functionality & Non-Functionality)

อ่านเพิ่มเติม

การอธิบายความต้องการ

การอธิบายความต้องการมีหลายชื่อให้เรียก อย่างแนวทางการพัฒนาระบบแบบ Object-Orientation เป็นแนวทางพัฒนาระบบบนแนวคิด Use Case Driven หรือ Function-Driven นั่นเอง จึงเรียกความต้องการหลักว่า use case ซึ่งก็คือฟังก์ชั่นนั่นล่ะ แล้วเรียกความต้องการทางคุณภาพว่า non-functional requirement หรือ special requirement หรือ supplimentary requirement ใช้หลักการรวมคือ ‘FURPS+’ (Functionality, Usability, Reliability, Performance, Supportability, และอื่นๆ อีกมากมาย) หรืออย่างในแนวทางพัฒนาระบบแบบ Agile มักเรียกความต้องการว่า use case หรือ user story หรือไม่ก็ใช้คำว่า use case แทนความหมายความต้องการ ส่วนคำว่า user story แทนความหมายการอธิบายความต้องการ

นอกจากนี้ความต้องการในงานพัฒนาซอฟต์แวร์ยังมีตั้งหลายประเภท อาทิ business goal, system feature, functional requirement/use case, non-functional requirement, glossary, system requirement, environment requirement, user requirement ฯลฯ หนำซ้ำบางทีมยังแบ่งระดับความต้องการอีกเป็น high level requirement, detailed requirement เละเทะซับซ้อนยุ่งเหยิงกันไปหมด คำถามที่ผมเจอบ่อยมากคือ ความต้องการนี้เป็นประเภทไหน? ควรจัดอยู่ในเอกสารไหนดี? หรือในหัวข้อไหนดี? โธ่! เอาเวลาไปอธิบายความต้องการให้ดีดีกว่าไหม? ไม่ต้องจัดให้มันมีหลายประเภทนักหรอกครับ คำตอบที่ได้รับกลับมาบ่อยครั้งก็คือ ก็ template (พวก SRS: Software Requirement Specification) มันมีแยกเป็นหัวข้อๆ… วุ้ย ช่างหัว template มัน ไม่ต้องแบ่งแบบนั้นเสมอไปก็ได้ อย่าให้ template มาชี้นำการทำงานจนเกินไป ควรให้ process ชี้นำมากกว่า จะแบ่งความต้องการเป็นกี่ประเภทก็ควรแบ่งให้เหมาะสมกับงาน มาเน้นการอธิบายความต้องการดีกว่าครับ…นะ (ดู ประเภทความต้องการ)

การอธิบายความต้องการมี  2 รูปแบบใหญ่ๆ คือ

  • แบบเรียบง่าย
    เป็นการอธิบายสั้นๆ ใช้ภาษาที่สั้นกระชับ เช่น มีปริมาณไม่เกิน 1-3 บรรทัดต่อ 1 ความต้องการ หรือไม่เกิน 1 สไลด์ใน MS PowerPoint (ใช้ตัวอักษรใหญ่ๆ นะ) หรือ 1 ความต้องการต่อกระดาษ post-it 1 แผ่น หรือ 1/6 ของกระดาษ A4 หรือการพูดบรรยายโดยใช้เวลาอธิบาย 1 ความต้องการสั้นๆ เช่น ไม่เกิน 1-3 นาทีต่อ 1 ความต้องการ (ดู User Story)
  • แบบละเอียด
    เป็นการอธิบายรายละเอียดแบบละเอียดๆ โดยแจกแจ่งเป็นประเด็นย่อยๆ เช่น การอธิบาย functional requirement หรือ use case ก็แบ่งเป็นหัวข้อ ชื่อความต้องการ, รหัสความต้องการ, brief description, pre-condition, post-condition, basic flow, alternative flows, special requirements เป็นต้น (ดู Use Case Specification) และ การอธิบาย non-functional requirement ก็แบ่งเป็นหัวข้อ stimulus, source of stimulus, artifact, environment, response, response measure (ดูการอธิบาย Quality Scenario ใน Non-Functional Requirement)

อ่านเพิ่มเติม

Use Case Specification

การอธิบาย functional requirement แบบละเอียด แนะนำรูปแบบการอธิบายแบบ ‘Use Case Specification’ หรือ บ้างก็เรียกว่า ‘Use Case Description’ เนื่องจากมีการแบ่งประเด็นเป็นหัวข้อๆ ชัดเจน ทำให้เราไม่ต้องการอธิบายเป็นข้อความยาวเหยียดเป็นเรียงความ ทำให้อ่านยากและจับประเด็นยาก

หัวข้อที่ควรอธิบายใน Use Case Specification มีดังนี้

  • ชื่อ หมายถึง ชื่อ use case ซึ่งควรใช้คำหรือข้อความสั้นๆ แล้วขึ้นต้นด้วยคำกริยา เพราะเวลาอ่านความต้องการ มักเริ่มอ่านจากไคลเอ็นต์หรือผู้ใช้มาที่ use case เช่น บุคคลทั่วไปสมัครสมาชิกทางอินเทอร์เน็ต
  • รหัส หมายถึง รหัส use case เนื่องจากทุกความต้องการและทุกประเภทควรมีรหัส ซึ่งควรขึ้นต้นด้วยอักษรย่อประเภทความต้องการ หรือขึ้นต้นด้วยรหัสระบบ แล้วปิดท้ายสุดด้วยลำดับตัวเลขของความต้องการ
  • Brief Description หมายถึง ข้อความบรรยายความต้องการสั้นๆ ไม่ควรเกิน 3 บรรทัด
  • Flow of Events หมายถึง ขั้นตอนที่ไคลเอ็นต์หรือผู้ใช้กระทำกับระบบ ย้ำนะครับว่าเป็นขั้นตอนที่ไคลเอ็นต์หรือผู้ใช้ใช้ระบบ ให้อธิบายในมุมว่าเขามาใช้ระบบ ไม่ใช่อธิบายในมุมระบบทำอะไรให้เขานะ เพราะเรากำลังอธิบายความต้องการ ซึ่งเป็นกิจกรรมในงาน requirement ที่เน้นที่ปัญหาและความต้องการ เพราะหากเผลอไปอธิบายในมุมระบบทำอะไรให้ไคลเอ็นต์หรือผู้ใช้ แสดงว่าสมาธิคุณหลุดไปคิดถึงโซลูชั่นแล้ว และนั่นมันคืองาน system analysis เพราะการคิดถึงระบบว่าจะทำอะไรมันคือการเข้าสู่งาน system analysis แล้ว และหากยิ่งถลำลึกอาจยิ่งเผลอหลุดลึกเข้าไปถึง system design โดยไม่รู้ตัว กลายเป็นว่ากำลังเขียนอธิบายความต้องการและโซลูชั่นปนกัน กลายเป็นการล็อกสเป๊กโซลูชั่นไปโดยไม่รู้ตัวFlow of Events มี 2 ประเภท ได้แก่ Basic Flow บางทีก็เรียกว่า Default Flow หรือ Main Flow หรือ Main Course (หยั่งกะอาหารแน่ะ) หรือ Success Flow และ  Alternative Flow บางทีก็เรียก Exceptional Flowการอธิบาย Flow of Events สามารถอธิบายบรรยายเป็นขั้นตอนก็ได้ หรือวาดเป็นรูป business process หรือ flow chart ก็ได้ แนะนำให้วาดด้วยไดอะแกรม BPMN (Business Model Notation) หรือ UML Activity Diagram เพราะละเอียด มีสัญลักษณ์ให้เลือกใช้หลากหลาย และได้มาตรฐาน

อ่านเพิ่มเติม

NFR Checklist: Portability, Maintainability & Manageability, Customizibility & Configureability

Checklist สำหรับใช้จับประเด็น เพื่อช่วยตั้งคำถามด้าน non-functional requirement ในงาน requirement, ช่วยออกแบบ non-functional test case, ช่วยออกแบบโซลูชั่น

 

NFR Checklist ด้าน Portability

ความต้องการ (Requirement)

สมมติฐาน (Assumption)

Platform

  • ระบบต้อง deploy บนสภาพแวดล้อมที่แตกต่างกันมากกว่าหนึ่งหรือไม่?
  • ถ้ามี เป็น platform อะไรบ้าง?
  • Legacy system หรือ external system ที่ระบบต้องไปเชื่อมต่อหรือทำงานร่วมด้วย (depend on) มีโอกาสที่จะเปลี่ยน platform หรือไม่? เช่น database server อาจเปลี่ยนเป็นยี่ห้ออื่นในอนาคต

Technology

  • แต่ละสภาพแวดล้อมมีเทคโนโลยีที่เหมือนกัน คล้ายกัน ต่างกันหรือไม่ อย่างไร?
  • มี constraint ใดบ้างที่ส่งผลกระทบต่อด้านเทคโนโลยี?

Programming Language

  • ภาษาโปรแกรมที่จะใช้พัฒนาระบบสนับสนุนด้าน portability หรือไม่ มากน้อยแค่ไหน?
  • มี constraint ด้านภาษาโปรแกรมหรือไม่?

Time / Schedule / Plan

  • มีกรอบ/เกณฑ์ในการ port ระบบหรือไม่?
  • มีการวางแผนไว้หรือไม่ว่าจะ port ระบบเมื่อไหร่ ที่ไหนบ้าง?

Reliability

  • มีจุดใดบ้างที่หากมีการ port ระบบแล้วต้องการให้มีความน่าเชื่อถือสูงๆ? เช่นคุณภาพการทำงานห้ามผิดเพี้ยน
  • มี constraint ใดบ้างที่ส่งผลกระทบต่อความน่าเชื่อถือ?

Modifiability

  • การ port ระบบต้องมีการ modify ส่วนใดส่วนหนึ่งหรือไม่?
  • ระบบที่จะพัฒนาทำงานอยู่บน middleware หรือไม่? ถ้ามียี่ห้ออะไร? เวอร์ชั่นอะไร? เป็น middleware ด้านไหน?

Manageability

  • กรณีหากระบบถูก deploy ไปยังสภาพแวดล้อมหลายที่ (multiple copy) จะบริหารจัดการอย่างไร?

Variability

  • เมื่อระบบต้องทำงานบนสภาพแวดล้อมที่แตกต่างกันได้ มี variation ใดหรือไม่?
  • มี variability point จุดใดบ้างที่ต้องพิจารณา? และส่งผลต่อคุณภาพและการทำงานของระบบอย่างไร? หรือส่งผลต่อธุรกิจอย่างไร?
  • มี constraint ใดบ้างที่ส่งผลกระทบต่อ variation ของคุณภาพและการทำงาน?

อ่านเพิ่มเติม

NFR Checklist: Security, Usability, Testability

Checklist สำหรับใช้จับประเด็น เพื่อช่วยตั้งคำถามด้าน non-functional requirement ในงาน requirement, ช่วยออกแบบ non-functional test case, ช่วยออกแบบโซลูชั่น   NFR Checklist ด้าน Security

ความต้องการ (Requirement)

สมมติฐาน (Assumption)

Business Actor

  • Business actor คือใคร?

Business Worker

  • Business worker คือใคร?

System Actor

  • System actor คือใคร? อยู่ที่ไหน? ติดต่อระบบผ่าน channel อะไร? ใช้โปรโตคอลอะไร?

Boundary

  • กำหนดขอบเขต (เช่น DMZ) อะไรบ้าง?
  • มี constraint ใดบ้างที่ส่งผลต่อ boundary?
  • ในแต่ละ boundary ประกอบด้วยทรัพยากรใดบ้าง?
  • แต่ละ boundary สื่อสารกันอย่างไร? กรณีใด?

Operation

  • Operation ใดบ้างที่มีผลต่อ security? เช่น modify, delete, access service

Artifact

  • สิ่งที่อาจได้รับผลกระทบหากมีปัญหาด้าน security คืออะไรบ้าง? เช่น ข้อมูล, operation, service, ทรัพยากร

Environment

  • สภาพแวดล้อมเป็นแบบใดได้บ้าง? เช่น online, offline, connected, disconnected, อยู่หลัง firewall หรือไม่มี firewall

Probability of Attack

  • มีโอกาสที่จะถูก attack แค่ไหน? จากใคร? จากที่ไหน?

Time/Effort/Resource

  • มีระยะเวลา/บุคลากร/ทรัพยากร แค่ไหน เท่าไรในการทดสอบ/ตรวจสอบ/แก้ไข ด้าน security?
  • และมี constraint ใดที่ส่งผลต่อทรัพยากรในการจัดการด้าน security บ้าง?

Action

  • มีการจัดการด้าน security อะไรบ้าง? เช่น authentication, authorization, grant/withdraw permission, transfer permission

Application Security

  • มีการใช้ information hiding ในจุดใดบ้าง?
  • มี single point of failure ในจุดใดบ้าง?
  • มีการใช้ pattern: Observer, Visitor, Proxy, Façade, Front Controller, Gateway ในจุดใดบ้าง? อะไรบ้าง? อะไรบ้าง?
  • มีการสร้าง abstraction layer ในจุดใดบ้าง?
  • มีการ access file, database, message queue server และทรัพยากรอื่นๆ ในจุดใดบ้าง?
  • การจัดการด้าน authentication, authorization, single sign-on จะพัฒนาเองหรือใช้เฟรมเวิร์กหรือใช้ middleware?
  • มีการทำ security data propagation ในจุดใดบ้าง?
  • การ parse หรือ convert ข้อมูล (เช่น XML, รูปกราฟฟิก) พัฒนาเองหรือใช้ไลบรารี่อื่น?

Reliability

  • มีจุดใดบ้างที่ต้องการความน่าเชื่อถือมากๆ?
  • มีจุดใดบ้างที่หากเกิดข้อผิดพลาดด้าน security แล้วส่งผลต่อความน่าเชื่อถือในส่วนต่างๆ? ส่งผลต่อส่วนใดบ้าง?

Performance

  • มีจุดใดบ้างที่จะมีการจัดการด้าน security ที่อาจส่งผลต่อประสิทธิภาพการประมวลผลและการใช้ทรัพยากร?
  • มี constraint ใดบ้างที่ส่งผลต่อประสิทธิภาพการประมวลผลและการใช้ทรัพยากร?

Availability

  • มีจุดใดบ้างที่หากถูก attack แล้วระบบจะล่มหรือหยุดทำงานหรือทำงานช้าลง

อ่านเพิ่มเติม

NFR Checklist: Performance, Scalability, Interoperability & Integrability

Checklist สำหรับใช้จับประเด็น เพื่อช่วยตั้งคำถามด้าน non-functional requirement ในงาน requirement, ช่วยออกแบบ non-functional test case, ช่วยออกแบบโซลูชั่น

 

NFR Checklist ด้าน Performance

ความต้องการ (Requirement)

สมมติฐาน (Assumption)

Incoming Event

  • การเกิดขึ้นของ event เนื่องจากการเข้ามาใช้ระบบโดยผู้ใช้ หรือ client เป็นแบบใด? เช่น periodic event, sporadic event, stochastic event
  • จำแนกตามอะไร? เช่น หน้าจอ, ฟังก์ชั่น, เซอร์วิส
  • จำนวนผู้ใช้ หรือ client ต่อวัน/ชั่วโมง/วินาทีคือเท่าไร?
  • จำนวน concurrent ของผู้ใช้ หรือ client เป็นเท่าไร? ณ ช่วงเวลาใดบ้าง?

Resource

  • ทรัพยากรที่จะใช้มีกี่ประเภท? เช่น หน่วยความจำ, I/O, ซีพียู, database server, ERP, network, directory server
  • Resource system มีอะไรบ้าง? ยี่ห้ออะไร? เวอร์ชั่นอะไร?
  • Network bandwidth ที่เหลือโดยเฉลี่ย(เช่น ต่อชั่วโมง) ที่เชื่อมต่อไปยัง resource system เหล่านั้นคือเท่าไร?
  • เครื่องที่ระบบนี้จะไป deploy มีทรัพยากรเหลือโดยเฉลี่ยเท่าไร? เช่น ต่อชั่วโมง ต่อวัน
  • มีทรัพยากรใดที่ถูกเข้าถึงพร้อมกันบ้าง (simultaneous access)? เกี่ยวข้องกับฟังก์ชั่นหรือกลไกใด?

Client Behavior

  • แบ่งผู้ใช้ หรือ client เป็นกี่ประเภท?
  • พฤติกรรมของผู้ใช้ หรือ client แต่ละประเภทเป็นอย่างไร?

Deadline

  • Deadline ของ process/transaction จะกำหนดที่เท่าไร? ในช่วงนี้อาจยังไม่ทราบชัดเจน เอาคำตอบแบบคร่าวๆ ก่อน เป็นช่วงเวลาหรือค่าประมาณ

Throughput

  • ปริมาณงานที่จะเสร็จต่อช่วงเวลาเป็นเท่าไร? เช่น ภายใน 1 ช.ม.ต้องประมวลผลคำสั่งสั่งซื้อให้เสร็จอย่างน้อย 100 คำสั่ง

Latency

  • ระยะเวลาหน่วงหรือดีเลย์ในการเข้าถึงทรัพยากรคือเท่าไรที่ยอมรับได้? เข้าถึงทรัพยากรใด? เช่น หาก request  เข้าไปถึง database แล้ว database จะใช้เวลาประมวลผล request นี้ไม่เกิน 1,000 มิลลิวินาที แต่พอ request ไปถึง database แต่ดันไม่ว่าง เข้าไม่ได้ request เลยต้องรอ เสียเวลารอไป 850 มิลลิวินาที พอเข้าได้แล้ว database ประมวลผล request ไป 1,000 มิลลิวินาที สรุปแล้วระยะเวลาเข้าใช้ database โดยรวมคือ 1,850 มิลลิวินาที คิดเป็นเวลา latency (หรือเวลาหน่วง/ดีเลย์) 850 มิลลิวินาที ดังนั้นระบบที่ต้องการความเร็วมากๆ จึงต้องหาทางลด latency ลง เพื่อให้ response time สั้นลง ซึ่ง latency สามารถเกิดได้ทุกจุดที่เป็น resource โดยเฉพาะ shared resource ที่ต้องใส่ใจมากๆ

Business Process

  • มี business process ให้วิเคราะห์หรือไม่?
  • Business process มีความละเอียดพอนำมาวิเคราะห์ประเด็นต่างๆ ในคำถามก่อนหน้าหรือไม่? (ในหลายงานจำเป็นต้องจูนทั้ง business (คนทำ) และ system (ระบบทำ))

Cost & Budget

  • มีงบประมาณสำหรับทรัพยากร/ฮาร์ดแวร์เท่าไร?
  • โดยประมาณเท่าไร?
  • ที่สามารถจ่ายได้สูงสุดไม่เกินเท่าไร?

อ่านเพิ่มเติม

NFR Checklist: Availability, Modifiability, Reliability

Checklist สำหรับใช้จับประเด็น เพื่อช่วยตั้งคำถามด้าน non-functional requirement ในงาน requirement, ช่วยออกแบบ non-functional test case, ช่วยออกแบบโซลูชั่น

 

NFR Checklist ด้าน Availability

ความต้องการ (Requirement)

สมมติฐาน (Assumption)

Action

  • หากระบบหยุด/ล่ม/ทำงานช้าผิดปกติ จะให้ response อย่างไร? เช่น record, notify, disable, continue, be unavailable

Boundary

  • Client ที่จะใช้ระบบอยู่ภายในองค์กรหรือมีเข้ามาจากนอกองค์กรด้วย?
  • ขอบเขตของระบบกำหนดชัดเจนแล้วหรือไม่?

Repair Time

  • หากระบบหยุด/ล่ม/ทำงานช้าผิดปกติ ต้องใช้เวลาในการหาสาเหตุไม่เกินเท่าไร? (หน่วยเป็นนาที/วินาที)
  • หากระบบหยุด/ล่ม/ทำงานช้าผิดปกติ ต้องใช้เวลาในการแก้ไขจนระบบกลับเป็นปกติไม่เกินเท่าไร? (หน่วยเป็นนาที/วินาที)

Availability Rate

  • อัตราความพร้อมของระบบคือเท่าไร? เช่น 99.999% ต่อปี (คิดเป็นเท่าไหร่ลองดูในลิงค์นี้ครับ https://en.wikipedia.org/wiki/Availability_(system))

Available Time Interval,

Unavailable Time Interval,

Degraded Time Interval

  • ช่วงเวลาที่ระบบต้องพร้อมให้บริการ/หรือพร้อมใช้งาน คือช่วงใดบ้าง? (ควรแบ่งเป็นช่วงๆ เช่น วัน, ชั่วโมง, นาที)
  • ช่วงเวลาที่ระบบหยุด/ปิดการทำงานคือช่วงเวลาใด?
  • ช่วงเวลาที่ระบบสามารถทำงานช้าหรือให้บริการช้าได้ (แต่ไม่เกินที่ระบุใน SLA) คือช่วงใด? เกิดจากสาเหตุใด?

Area of Concern

  • ส่วนใดของระบบ (เช่น ฟีจเจอร์, หน้าจอ) ที่ stakeholder concern มากๆ? เช่น หยุดทำงานไม่ได้/ช้าไม่ได้ เด็ดขาด

อ่านเพิ่มเติม

Quality Attribute (Non-Functional Requirement)

NFR_QA

Quality Attribute คือ คุณสมบัติเชิงคุณภาพของสิ่งต่างๆ ภายในระบบที่มีการทำงาน เช่น สถาปัตยกรรมระบบ โมดูล อ็อบเจ็คต์ หน้าจอ เป็นต้น และรวมถึงคุณภาพของระบบและระหว่างระบบภายในบริบทเดียวกัน เนื่องจากสิ่งต่างๆ เหล่านี้ต้องมีการประมวลผล มี input และมี output เกิดขึ้น การจะให้ทำงานได้มีคุณภาพที่ดีจึงมีการกำหนดคุณสมบัติเชิงคุณภาพเอาไว้ โดยควรมีคุณภาพอะไรบ้างก็ขึ้นกับบริบทของระบบนั้นๆ ว่า stakeholder ต้องการระบบที่มีศักยภาพแค่ไหน

FunctionMechanismQA

การกำหนด Quality Attribute ได้มาจากการเก็บรวบรวมความต้องการประเภท Non-Functional Requirement โดยเจ้า Quality Attribute เองก็ยังแบ่งออกได้เป็น 3 ประเภท ได้แก่

  • System Quality คือ คุณภาพระบบ มีหลักๆ อยู่แค่ 6 ตัว ได้แก่ Availability, Modifiability, Performance, Security, Testability และ Usability ซึ่งเจ้า System Quality นี่ล่ะที่เราๆ มักเรียกอีกอย่างว่า ‘Non-Functional Requirement’ นั่นเอง
  • Business Quality คือ คุณภาพในเชิงธุรกิจที่ระบบได้สนองต่อธุรกิจของ stakeholder มีหลายตัว มักเป็นศัพท์ธุรกิจ อาทิ Increase Net Profit, Increase Competitiveness, Short Time to Market, Reduce Paper Work เป็นต้น ถ้าสังเกตให้ดี ก็จะร้องอ๋อ…ว่ามันก็คือ Business Goal นั่นเอง แต่ต่างๆ เล็กน้อยที่ขอบเขตและ Level of Abstraction เพราะ Business Goal เป็นการมองภาพรวมของทั้งระบบหรือทั้งโครงการ แต่ Business Quality สามารถใช้มองในระดับที่ลึกในรายละเอียดกว่าได้ เช่น Business Quality ของ Domain Layer, ของโมดูล Report Manager, ของกลไก Transaction Management, ของสถาปัตยกรรมระบบ เป็นต้น
  • Architecture Quality คือ คุณภาพของสถาปัตยกรรมระบบ ไม่ได้มองที่การทำงานแบบ System Quality แต่มองที่ประโยชน์และการนำไปใช้ มีไม่มากนัก อาทิ Conceptual Integrity, Buildability, Correctness and Completeness เป็นต้น

อ่านเพิ่มเติม

Architectural Requirement Context

ArchReqContext

สมัยนี้มีความต้องการเพิ่มจากแต่ก่อนหลายประเภท ประเภทหนึ่งที่เริ่มได้ยินกันบ่อยขึ้นคือ ‘Architectural Requirement’ ซึ่งในบทความนี้ขอนำเสนอในมุมบริบทสำหรับความต้องการที่มีผลต่อการออกแบบและสร้างสถาปัตยกรรมซอฟต์แวร์ และมีผลต่อซอฟต์แวร์โดยรวม

สำหรับคำว่า ‘Architectural Requirement’ หมายถึง ความต้องการสำหรับการออกแบบและสร้างสถาปัตยกรรมซอฟต์แวร์ ซึ่งจริงๆ มันก็คือ non-functional requirement หรือ quality attribute นั่นเอง แต่เนื่องจากความต้องการประเภทนี้มีความสำคัญมากๆ ต่องานสถาปัตยกรรมนั่นเอง จึงมีคนคิดความต้องการประเภทใหม่แล้วตั้งชื่อว่า ‘Architectural Requirement’ ให้มันชัดเจนไปเลยนั่นเอง

สำหรับบทความนี้มีรายละเอียดหลายประเด็น ขอให้ภาพรวมเพื่อให้เข้าใจง่ายๆ ไว้ดังนี้ครับ: เมื่อเริ่มโครงการ เราต้องวิเคราะห์ปัจจัยภายนอก แล้วดูว่า stakeholder มีความกังวลต่อเรื่องใดบ้าง พวกเขาต้องการอะไร อยากให้มีระบบไอทีอะไรไปช่วย อยากให้ระบบไอทีทำอะไรได้บ้าง เมื่อเราเข้าใจภาพรวมแล้ว ก็เก็บรวบรวมความต้องการ โดยเฉพาะ functional requirement หรือ use case และ non-functional requirement หรือ quality attribute แล้วอธิบายเป็น quality scenario ความต้องการใดที่วิเคราะห์แล้วเข้าใจแล้วรีบเอาไปเขียน test case ไม่ว่าด้าน functional test case และ non-functional test case จากนั้นรีบไปหาโซลูชั่น โซลูชั่นที่ได้ก็ต้องวิเคราะห์ประโยชน์ว่าคุ้มไหมดีไหม แล้วรีบออกแบบและพัฒนาระบบ…ประมาณนี้ครับ รูปข้างบนเป็นการอธิบายความสัมพันธ์ระหว่างประเด็นสำคัญต่างๆ อ้อ…ในงานสถาปัตยกรรมซอฟต์แวร์เน้นโซลูชั่นด้านกลไกการทำงานภายใน (architectural mechanism) มากกว่าฟังก์ชั่นนะครับ

อ่านเพิ่มเติม