สงคราม Algo Trading Robot

ต่างประเทศและในบ้านเราเริ่มมีหลายคนหันมาทำหลักสูตรและเผยแพร่ความรู้ผ่านสื่อออนไลน์ในการสร้างหุ่นยนต์เทรด (Alrotihmic Trading Robot หรือ เรียกสั้นๆ ว่า Algo Trading Robot หรือสั้นขึ้นอีกเป็น Trading Robot) บางคนก็รับเขียนโปรแกรม Algo Trading Robot ให้ผู้ที่สนใจอยากลงทุนผ่านหุ่นยนต์ บางองค์กร เช่น กองทุนและโบรกเกอร์หลายราย (ซึ่งกำลังมีจำนวนเพิ่มมากขึ้นเรื่อยๆ) ได้เปิดให้บริการ Algo Trading Robot แก่ลูกค้าอย่างเป็นทางการ… จึงเป็นที่มาของข้อสงสัยที่เคลือบแคลงใจคนจำนวนมากว่า หุ่นยนต์เหล่านั้นน่าเชื่อถือเพียงใด และ ผู้ที่ทำหลักสูตร, เผยแพร่ความรู้, และที่ให้บริการที่ไม่ใช่สถาบันการเงิน น่าเชื่อถือเพียงใด

มีการกล่าวถึงกันมากมายทั่วโลกว่า Algo Trading Robot จะมาสร้างความปั่นป่วนให้ตลาดหุ้นและตลาดทุนอื่นๆ ดังที่เคยก่อเหตุมาแล้วในตลาดหุ้นสหรัฐและตลาดบ้านเราก็เคยเจอ ที่หุ่นยนต์เทรดส่งคำสั่งซื้อ/ขายจำนวนมากในเวลาไล่เลี่ยกัน จนทำให้เกิดการไล่ราคาอย่างรวดเร็ว ส่งผลให้ราคาหลักทรัพย์และดัชนีตลาดเปลี่ยนแปลงอย่างฉับพลันอย่างหนัก สร้างความเสียหายมหาศาลในเวลาอันสั้น

และยิ่งในปัจจุบันที่มีการนำ AI, Machine Learning และ Data Science มาใช้ในการสร้าง Algo Trading Robot กันมากขึ้น มันจะฉลาดขึ้นจริงหรือ? คนที่ใช้จะคุ้มค่าได้กำไรจริงหรือ? เมื่อแนวโน้มจะมีคนหันมาลงทุนผ่านหุ่นยนต์เหล่านี้กันมากขึ้น

robotfight

credit ภาพ: http://www.smh.com.au/

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

Advertisements

หลักสูตรอบรม Algo Trading

หลักสูตรอบรม: ออกแบบและสร้าง Algorithmic Trading System

สำหรับผู้สนใจงาน Quant, Quant Developer, Quant Architect และ ผู้ที่ต้องการมีหุ่นยนต์เทรด/ลงทุนไว้ใช้งานส่วนตัว

*ผู้สนใจสมัครเรียน รบกวนส่ง message มาที่เฟสบุ๊กผมได้ครับที่ https://web.facebook.com/narong.chansoi.5

ผู้ที่ไม่ได้เรียนและทำงานด้านไอทีก็เรียนได้ครับและจะดีด้วยในการช่วยทำเวิร์กช็อปหลายส่วน

เป็นกิจกรรมแบบฮาร์ดคอร์ ต้องการคนที่ซีเรียสจริงจังหน่อยครับ

ผู้เรียนจะได้เรียนตั้งแต่พื้นฐานการเทรด/ลงทุน ไปจนถึงการนำ Deep Learning, AI, Machine Learning มาใช้

artificial-intelligence

เครดิตรูปภาพ: http://jonathankinlay.com/

การจัดกิจกรรมจะจัดไม่เกิน 2 ครั้งเท่านั้น และจะไม่จัดอีกแล้ว (เพราะผมจะหาทุนวิจัยและหาผู้ร่วมอุดมการณ์มาร่วมทีม ไม่ได้จะทำเป็นธุรกิจ) ยกเว้นจัดกิจกรรมฝึกอบรมการเทรด/ลงทุนสำหรับผู้พิการและคนชราที่วางแผนจะจัดในอนาคตเท่านั้น กิจกรรม/การจัดอบรมนี้ไม่ใช่การชวนมาเรียนง่ายๆ รวยง่ายๆ ไม่ใช่การระดมทุน ไม่ใช่แชร์ลูกโซ่ ไม่ต้องการคนจำนวนมาก ไม่ต้องการเงินจำนวนมาก ขอแค่พอใช้ระหว่างทำ R&D และทำกิจกรรมร่วมกันครั้งต่อๆ ไป และเป็นแบบปิด

กิจกรรมนี้จะไม่มีออนไลน์หรือ Live นะครับ เพราะต้องการเจอกันคุยกันตัวเป็นๆ แต่พอหลังจบกิจกรรมพอสนิทกันแล้วก็คุยและทำงานร่วมกันผ่านออนไลน์ได้ครับ

สำหรับผู้ที่สนใจอยากเป็นสปอนเซอร์สนับสนุนงานวิจัยและพัฒนา และ/หรืออยากมี trading robot และระบบไอทีไว้ใช้งาน (เฉพาะตลาดหุ้น, FOREX, gold future, oil future) หรืออยากได้ผลงานวิจัยไปใช้ต่อยอด ก็ติดต่อได้ครับ

จำนวนวันอบรม: 12 วัน (ทำไมตั้ง 12 วันแน่ะ! รบกวนอ่านไปเรื่อยๆ และอ่านหัวข้อดูก่อนครับ) ไม่ได้เรียนติดกันทุกวัน สำหรับวันเรียนไว้จะนัดกันอีกทีเพื่อให้สะดวกกันทุกคน

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

R&D Statement

ผมกำลัง R&D เกี่ยวกับ Algorithmic Trading System Architecture for Multi-Asset and Multi-Market โดยสร้าง Trading Platform ขึ้น ความคืบหน้า ณ ปัจจุบัน คือกำลังสร้าง trading robot ต้นแบบ โดยใช้ Machine Learning และ Deep Learning แบบจัดเต็ม เพื่อนำตัวต้นแบบไปโคลนนิ่งสร้างเป็น trading robot ตัวใหม่ๆ สำหรับเทรด/ลงทุนในสินทรัพย์ต่างๆ ได้รวดเร็วและประหยัดเวลาเขียนโปรแกรมสร้าง trading robot ตัวใหม่ๆ ลง เพื่อให้สามารถรองรับกลยุทธ์การเทรด/ลงทุนที่หลากหลายได้

ปัจจุบันผมสร้าง trading engine และ trading robot ใช้งานจริงอยู่ ใช้มาสักพักใหญ่แล้ว โดย trading robot แต่ละตัวใช้เวลาเขียน โปรแกรม, ทดสอบ และ optimize นานมากกว่าจะเสร็จ งาน R&D นี้ ได้นำหลายหลักการมาใช้ เพื่อให้สามารถสร้าง trading robot ตัวใหม่ๆ ได้อัตโนมัติหรือกึ่งอัตโนมัติ เพื่อประหยัด โดย เฉพาะตอนทดสอบ และ ตอน optimize

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

จุดเริ่มต้นของผมกับ Algo Trading

หลายปีมานี้ผมหันมาสนใจงานด้าน Algorithmic Trading หรือมักเรียกสั้นๆ ว่า ‘Algo Trading’ เนื่องจากตอนแรกตั้งใจว่าฝึก ‘เล่น’ หุ้น หารายได้เสริม ไปๆ มาๆ ดันชอบและคิดว่าเข้ากับนิสัยผมมาก…

ต่อมาจึงเริ่มศึกษาด้านการเทรดและลงทุนอย่างจริงจัง และเนื่องด้วยประสบการณ์ด้านไอทีทำให้ผมมองโลกการลงทุนแบบนักไอที ใช้ logical thinking, systematic thinking ตีความทุกอย่างเป็นตรรกะและเป็นระบบ และจากประสบการณ์ในงาน software architecture ทำให้ถนัดมองภาพรวมและการคิดและวิเคราะห์ข้อมูลแบบบูรณาการ (integrated thinking & analysis) และในการทำงานด้าน Software Architecture และ Enterprise Architecture ผมต้องคลุกคลีอยู่กับการบริหารความเสี่ยงจนรู้สึกไม่ได้กลัวความเสี่ยงเว่อร์มากแบบคนจำนวนมาก ความเสี่ยงมีไว้ให้บริหารก็แค่นั้น ไม่ต้องไปกลัวมัน

เพียงไม่กี่เดือนหลังเข้าสู่ตลาดหุ้นผมก็เริ่มออกแบบระบบเทรด (Trading System) ใช้เวลาอยู่ 1 ปี จากนั้นจึงนำมาเขียนเป็นโปรแกรม และศึกษาด้าน Machine Learning, AI, Deep Learning, Data Science, Data Analytics อย่างบ้าคลั่ง ผมออกแบบและพัฒนาระบบพวกนี้มาราว 3 ปีแล้ว เป็นงานที่ทำแล้วมีความสุขและสนุกมาก ในอดีตเคยแต่ไปสอนหนังสือ เป็นที่ปรึกษา และทำงานให้ลูกค้า การมาทำโปรเจ็คต์นี้มันเป็นการได้ออกแบบระบบและเขียนโปรแกรมใช้งานเอง คิดเอง เลือกใช้สิ่งต่างๆ เอง อยากเพิ่มอยากปรับอะไรก็ลุยไม่ต้องไปถามใครหรือขออนุญาตใคร ผลงานที่ได้ออกมาดีทีเดียว เกินคาดและมาไกลกว่าที่คิดไว้ในตอนเริ่มต้น ผมจึงมุ่งมั่นทำมันต่อมาเรื่อยๆ จนปัจจุบัน

การสร้างระบบนี้ขึ้นมาตั้งใจให้กองทัพ Trading Robot ของผมออกไปทำมาหากินให้ เพราะผมมีความฝันที่อยากจะทำอะไรต่างๆ หลายอย่าง ที่อยากทำก่อนตาย Algorithmic Trading System จึงเป็นเครื่องจักรหาเงิน ส่วนผมก็ออกไปทำตามฝัน

โครงการที่ผมตั้งใจจะทำในอนาคต:

  • เผยแพร่ความรู้ผ่านออนไลน์
  • เขียนหนังสือ
  • ทำมูลนิธิเกี่ยวกับเด็ก คนพิการ คนชรา
  • ทำมูลนิธิช่วยเหลือผู้มีไอเดียแต่ขาดแรงบันดาลใจและการสนับสนุน
  • ทำธุรกิจ social enterprise ช่วยเหลือองค์กรที่ประสบปัญหาด้านไอที โดยจะสร้างบุคลากรด้าน solution architect จำนวนมากเพื่อเข้าไปช่วยองค์กรเหล่านั้น
  • ทำโรงเรียนพัฒนาครูแนววอลดอร์ฟ และโรงเรียนเด็กเล็กแนววอลดอร์ฟ
  • เทคโอเวอร์โรงเรียนเด็กเล็กขนาดเล็กที่ประสบปัญหาธุรกิจมาปรับปรุงระบบการสอน
  • ทำโครงการฝึกอบรมการเทรด/ลงทุนสำหรับผู้พิการและคนชรา
  • การเกษตรแนว smart farming, digital farming
  • ทำธุรกิจ social enterprise เกี่ยวกับการท่องเที่ยวพร้อมไปทำบุญและไปช่วยเหลือชุมชนยากไร้ห่างไกล
  • ทำรีสอร์ทเล็กๆ แนวบ้านๆ เน้นธรรมชาติ

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

ธนาคารแบบดั้งเดิมกำลังจะเปลี่ยนไปในอนาคต เมื่อเทคโนโลยีก้าวล้ำขึ้น จนเปลี่ยนพฤติกรรมผู้บริโภคไป ธนาคารก็ย่อมปรับตัวตาม โดยจะปรับไปเป็น 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 แล้วระบบจะล่มหรือหยุดทำงานหรือทำงานช้าลง

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