Project Management and Software Development Blog for Thais

มีเพื่อนคนนึงอยากรู้ว่าการพัฒนาระบบขึ้นมาซักระบบต้องทำอะไรบ้างตั้งแต่ต้นจนจบ วันนี้ผมก็เลยรวบรวมข้อมูลมาให้ แต่เนื่องจากข้อมูลมันเยอะมากครับ ผมขอแบ่งเป็นบทความย่อยนะ เรามาเริ่มกันเลยครับ

ข้อมูลเบื้องต้นเกี่ยวกับ Project

หลังจากบริษัท XYZ Technology จำกัด ซึ่งเป็น Software house เล็กๆที่ถนัดงานที่เกี่ยวกับ Web application ทุกชนิดชนะการประมูลโครงการพัฒนาระบบเช่าหนังสือออนไลน์ให้กับร้านหนังสือยักษ์ใหญ่แห่งหนึ่งแล้ว คุณเจ้าของบริษัทก็บอกข่าวดีนี้กับสมาชิกทุกคนก่อนประกาศเริ่ม Project ทันที โดย Project นี้มี Project Sponsor (ก็ตัวเจ้าของเอง) 1 คน Project Manager 1 คน Business Analyst 1 คน Developer 3 คน และ QA 2 คน รวมเป็น 8 คน … ขนาดกำลังดีเลยครับ

Requirement คร่าวๆของ Project นี้ก็คือทำ Web application สำหรับการเช่าหนังสือออนไลน์ที่มี

• ระบบจัดการการเช่าหนังสือ (Rental module)
• ระบบเพิ่ม-ลดหนังสือ (Book management module)
• ระบบจัดการข้อมูลลูกค้า (User management module)
• ระบบการจ่ายเงินออนไลน์ (Payment module)
• และระบบการจัดการเวปไซต์ (Administration module)

ทั้งหมดนี้ต้องทำให้เสร็จภายในเวลา 5 เดือน

ภาพรวมของงาน

ผมเคยเขียนบทความเกี่ยวกับภาพรวมของการทำ Software development project ไปแล้วที่นี่ วันนี้ขอทบทวนคร่าวๆอีกครั้งครับ การทำ Software development project ประกอบด้วยสองส่วนสำคัญนั้นคือ 1. Software development และ 2. Project management ซึ่งงานทั้งสองด้านจะต้องทำควบคู่กันไปตั้งแต่เริ่มต้นจนจบเลย

สำหรับภาคแรกนี้ผมจะขอเน้นไปที่ช่วงแรกของ Project ซึ่งจะประกอบไปด้วยการทำ Requirement และ Design เบื้องต้นในส่วนที่เป็น Software development ครับ


ถ้าดูจากรูปจะเหมือนว่าผมข้ามส่วนที่เป็น Initiation กับ Concept ไป จริงๆแล้วเป็นแบบนี้ครับ สองขั้นตอนที่ว่านี้เกี่ยวข้องโดยตรงกับการพิจารณาว่า Project นี้ควรจะมีหรือไม่ แล้วถ้ามีต้องทำอะไรบ้าง ในกรณีของเราบริษัทหนังสือมองเห็นโอกาสทางธุรกิจว่า ?เอ้อ ถ้าเราต่อยอดธุรกิจโดยให้บริการเช่าหนังสือออนไลน์มันน่าจะเพิ่มกำไรให้บริษัทได้มากอยู่นะ? จากวิสัยทัศน์ของลูกค้าก็กลายมาเป็น Project ครับ จากนั้นลูกค้าก็จะมองแนวโน้มทางธุรกิจต่อไปว่า ?เอ่ ได้ข่าวแว่วๆมาว่าบริษัทหนังสืออีกรายก็กำลังมองๆธุรกิจแบบนี้อยู่เหมือนกันนะ ไม่ได้การล่ะ แบบนี้ต้องเราต้องชิงลงมือก่อน เราต้องเปิดเวปไซต์นี้ให้ได้ภายใน 6 เดือนเพื่อชิงความได้เปรียบ? จบตรงนี้เราได้กำหนดเวลาคร่าวๆของ Project มาแล้วครับ ลูกค้าก็จะคิดนั่นนี่ต่อไปอีกหน่อยเพื่อให้ได้มาซึ่ง Requirement เบื้องต้น ก่อนเปิดประมูลเพื่อหาบริษัทมาทำระบบให้เค้า

เพื่อนๆจะเห็นว่า Concept ถูกทำจนเสร็จเรียบร้อยแล้วโดยลูกค้าเอง ผลลัพธ์ที่ได้ออกมาก็คือตัว Project กับ Requirement เบื้องต้นที่ถูกส่งมาให้เรา ถ้าเพื่อนๆอยากรู้เพิ่มเติมที่มาที่ไปของ Project หรือ Requirement ลองอ่านบทความนี้ดูครับ

สำหรับส่วนที่เป็น Initiation นั้นเป็นงานในส่วนที่บริษัทของเราเองต้องรับผิดชอบในเรื่องการพิจารณาความเป็นไปได้ในการเข้าร่วมประมูล นั่นรวมถึงการศึกษาทางการเงินด้วยว่าถ้ารับ Project นี้มาแล้วจะได้กำไรคุ้มค่าหรือไม่ ราคาประมูลควรเป็นเท่าไร

ในอีกมุมหนึ่งเราก็ต้องเตรียมทีมงานที่จะมาทำ Project นี้ไว้คร่าวๆด้วยครับ ซึ่งหน้าที่ตรงนี้ก็เป็นของ Project Sponsor คนที่มีอำนาจตัดสินใจว่าจะเข้าประมูลหรือไม่อย่างไร แล้วก็เป็นคนเลือก Project Manager ซึ่งจะมารับช่วงต่อในการเตรียมข้อมูลที่ต้องใช้ในการตัดสินใจของต่างๆของ Project Sponsor นั่นรวมถึงข้อดี ข้อเสีย โอกาส ความเสี่ยง ความพร้อมของบริษัทเราเอง ทุกเรื่องแหละครับ อีกคนที่สำคัญก็คือ Business Analyst ซึ่งมีความรู้ในงานที่เกี่ยวกับ Web application ดีก็ต้องช่วยให้คำปรึกษาและดูความเป็นไปได้ต่างๆในแง่ Technical กับ Project Manager ครับ

สุดท้ายเราชนะประมูล Project นี้เรียบร้อย เริ่มงานกันเลยดีกว่าครับมีเวลาแค่ 5 เดือน (เพื่อนๆอาจจะงงว่า ลูกค้าอยากให้เปิดเวปไซต์ภายใน 6 เดือน แต่ทำไมผมบอกว่าเรามีเวลาแค่ 5 เดือน สาเหตุก็เพราะกระบวนการ Initiation กับ Concept กินไป 1 เดือนแล้วครับ เลยเหลือแค่ 5 เดือนให้เราพัฒนาระบบจริง)

Software Development Life Cycle — Requirement

ก่อนเราจะสร้าง ?อะไรซักอย่าง? เราต้องเข้าใจก่อนว่า ?อะไรซักอย่าง? มันคืออะไร (ไม่งงนะครับ) กระบวนการทำให้เราเข้าใจและเขียนเอกสารเกี่ยวกับ ?อะไรซักอย่าง? ก็คือ Requirement Analysis ครับ เพื่อให้ง่ายต่อการทำงานทั้งกับลูกค้าและในทีมเอง การทำ Requirement Analyst จะถูกแบ่งออกเป็นสองส่วนได้แก่ Customer requirements (C-requirements) และ Developer requirements (D-requirements) สองส่วนนี้แตกต่างกันทั้งในมุมมอง เทคนิคที่ใช้ และผลลัพธ์ที่ได้ครับ เรามาดูทีละส่วนกันเลย

Customer Requirement (C-requirements)

ในขั้นตอนนี้จะเป็นการเขียนเอกสารที่บอกถึง Requirement ทั้งหมดของระบบเช่าหนังสือเราโดยใช้ภาษาที่ลูกค้าเข้าใจได้ง่าย โดยทั่วไปแล้วตรงนี้จะเป็นหน้าที่ของ Business Analyst ที่จะทำการติดต่อพูดคุยกับลูกค้าโดยตรงเพื่อเก็บข้อมูลที่สำคัญก่อนส่งต่อให้ Developer ในขั้นตอนต่อไป

สาเหตุที่เราต้องมี C-requirements ก็เพราะว่าบางครั้งลูกค้าวาดภาพระบบที่อยากได้ออกมาแบบไม่ชัดเจนมากนัก แถมลูกค้าหลายคนก็มองระบบที่อยากได้ต่างกันอีก (อันนี้ธรรมชาติมากๆ) เช่น ถ้าพูดถึงระบบเช่าหนังสือ ในฐานะลูกค้าเพื่อนๆคิดถึงอะไรกันบ้างครับ?

• อยากได้แบบง่ายๆทั่วไป add/delete user, add/delete book อะไรแบบนี้แหละ
• อยากได้ระบบที่การจัดคิวลูกค้าถ้าหนังสือเล่มนั้นไม่ว่างด้วยนะ
• อ้อ แล้วถ้าหนังสือเล่มนั้นถูกคืนมาแล้ว ระบบต้องจัดการแจ้งลูกค้าคนแรกในคิวเลยนะ
• ผมอยากได้ระบบที่เชื่อมต่อกับไปรษณีย์เพื่อจัดส่งหนังสือให้ถึงมือลูกค้าได้เลย
• เอ่ แต่ดิฉันว่า … ระบบเช่าหนังสือมันน่าจะมีแต่หน้าร้านนะ ทำไมต้องมีแบบออนไลน์หละ งั้นเรื่องจัดส่งก็ไม่จำเป็นซักหน่อย
• ผมว่ามันต้องครบวงจรกว่านี้นะ ต้องมีระบบติดต่อสำนักพิมพ์เพื่อดึงข้อมูลหนังสือใหม่ๆมาแสดงที่เวปไซต์เราด้วย
• เอ้อ เห็นด้วยๆ แต่จะให้ดีดิฉันว่าให้มีระบบ email marketing ด้วยเลยนะ ลูกค้าเราจะได้รับข่าวสารโปรโมชั่นหรือหนังสือใหม่ๆอัตโนมัติ
• …
  

ถ้าเราไม่มีข้อมูลที่ชัดเจนว่าจริงๆแล้วลูกค้าอยากได้อะไร (Concept of Operations) โอกาสที่ Project จะล้มเหลวเพราะการเปลี่ยนแปลงที่จะเกิดขึ้นระหว่างเราทำงานก็มีสูงมาก ความสำคัญก็อยู่ตรงนี้แหละครับ สิ่งที่ท้าทายก็คือส่วนมากแล้วลูกค้าจะขาดความรู้ความเข้าใจทางด้านเทคนิคลึกๆ ดังนั้นเราจำเป็นต้องหาเทคนิคที่เหมาะสมมาใช้ เช่น Use cases, Data flow diagram หรือ Drafting user interface เป็นต้นครับ

Use Cases

โดยทั่วไปแล้ว Requirement จะถูกระบุออกมาเป็นความสัมพันธ์ระหว่างระบบ (system) และผู้ใช้ (user) ดังนั้นเราจะใช้ use case เพื่ออธิบายถึง System functionality ต่างๆที่จะให้บริการกับลูกค้า จากตัวอย่างที่ผมยกมาก็เช่นเราจะมีระบบจัดการการเช่าหนังสือ (Rental Module) ระบบเพิ่ม-ลดหนังสือ (Book Management Module) ระบบจัดการข้อมูลลูกค้า (User Management Module) ระบบการจ่ายเงินออนไลน์ (Payment Module) และระบบการจัดการเวปไซต์ (Administration Module) ทั้งหมดนี้จะถูกระบุให้ชัดเจนขึ้นด้วย use case ผมเขียน use case diagram กับ data flow diagram แบบคร่าวๆไว้เป็นตัวอย่างครับ


Data Flow Diagram

บางครั้งลูกค้าพยายามอธิบาย Requirement โดยใช้การไหลของข้อมูลผ่านกระบวนการต่างๆ ในกรณีนี้เราสามารถใช้ Data flow diagram เป็นเครื่องมือช่วยได้อย่างดีเลยครับ เช่นกระบวนการ Login ซึ่งต้องการข้อมูลคือ Username และ Password ถ้าถูกต้องระบบก็จะดึงข้อมูลของ Customer คนนั้นจากฐานข้อมูลตารางชื่อ Customer ก่อนส่งให้หน้าเวปเพื่อแสดงผลเป็นต้น

มีอีกหลายเทคนิคที่ใช้เพื่อสร้าง C-requirements เช่น state transition diagram หรือ activity diagram ลองหาข้อมูลเพิ่มเติมดูได้ที่นี่ครับ

User Interface

Requirement ที่เป็นตัวอักษรในเอกสารหรือรูปภาพที่เป็น diagram นั้นอาจจะตอบโจทย์ของลูกค้าและตัวเราได้ไม่ครบถ้วน โดยเฉพาะอย่างยิ่งข้อมูลและเอกสารพวกนั้นบอกลูกค้าไม่ได้ว่าสุดท้ายแล้วระบบที่ออกมาจะมีหน้าตาเป็นยังไง เรามาใช้ Drafting User Interface แก้ปัญหานี้กันดีกว่าครับ

จริงๆแล้ว User interface นั้นเป็นกระบวนการหนึ่งใน Design phase ของ Software development life cycle แต่ไม่เป็นไรครับเรามองว่างานนี้เป็นส่วนหนึ่งของ Requirement phase ได้เหมือนกันถ้าเราทำแค่ Draft user interface ครับผม ที่เราต้องใช้เทคนิคนี้ก็เพราะโดยทั่วไปแล้วลูกค้ามักจะมองเห็นภาพระบบเป็น Graphic user interface (GUI) เป็นหลัก ถ้าเราทำหน้าตาของระบบคร่าวๆไปให้ดู ลูกค้าจะมีโอกาสได้ให้ความคิดเห็นว่าอะไรขาด อะไรเกิน ในขณะเดียวกันก็เป็นการสร้างความเข้าใจในเรื่องหลักการทางธุรกิจ (Business function) ให้กับลูกค้าและตัวเราด้วยครับ

กระบวนการนี้ Business Analyst รับหน้าที่หนักหน่อยนะครับ แต่รับรองได้ว่าคุ้มค่าแน่นอน หลังจากเราเขียน C-requirements เสร็จแล้ว เราต้องมีการรีวิวเจ้าเอกสารเหล่านี้กับลูกค้าจนกว่าจะได้ข้อสรุปสุดท้ายก่อนที่จะส่งข้อมูลนี้ให้กับ Developer เพื่อทำ D-requirements ในขั้นตอนต่อไปครับ

Developer Requirement (D-requirements)

ตอนนี้เรารู้แล้วครับว่าลูกค้าอยากได้อะไร ขั้นตอนต่อไปก็คือจะทำยังไงให้ลูกค้าได้ตามนั้น กระบวนการนี้เป็นหน้าที่ของ Developer และ Business Analyst ที่จะทำงานร่วมกันเพื่อแปล C-requirements ออกมาเป็น D-requirements ซึ่งเป็นเอกสารที่ระบุคุณสมบัติ (properties) และความสามารถ (functionalities) ทั้งหมดที่ระบบต้องมีอย่างละเอียด D-requirement ถูกสร้างมาเพื่อ Developer โดยเฉพาะเลยครับดังนั้นมีคำศัพท์เทคนิคอะไรใส่เข้าไปได้หมด D-requirements ประกอบด้วย requirement หลักๆสามแบบคือ Functional, Nonfunctional, และ Inverse requirements ครับ

Functional Requirements

Functional requirements จะพูดถึงความสามารถหรือบริการต่างๆที่ระบบต้องตอบสนองผู้ใช้ได้ ถ้าพิจารณาจากระบบเช่าหนังสือออนไลน์ของเรา เพื่อนๆคิดถึง functional requirements อะไรบ้างครับ?

• ระบบต้องสร้าง/ลบ user ได้
• ระบบต้องแก้ไข user profile ได้
• ระบบต้องค้นหาหนังสือได้โดยระบุชื่อหนังสือ รหัสหนังสือ ชื่อผู้แต่ง และวันที่ตีพิมพ์
• ระบบต้องจัดการคำขอเช่าหนังสือจาก user ได้
• ระบบต้องจัดการการชำระเงินด้วยบัตรเครดิต Visa, Mastercard และ Paypal ได้
• ระบบต้องมีส่วนการช่วยเหลือ user
• ระบบต้องมีการจัดการคิวของหนังสือและ user
• ?
  

Nonfunctional Requirements: Performance Requirements

Performance requirements ส่วนใหญ่แล้วเกี่ยวข้องกับเวลา ความจุ และการใช้ทรัพยากรของเครื่องซึ่งระบบต้องตอบสนองให้ได้ เช่นเรื่องของ speed, capacity, และ memory and storage usage ครับ โดยทั่วไปแล้ว Performance requirements นี้จะสำคัญมากสำหรับระบบที่เป็น real-time เช่นระบบป้องกันการชน ระบบควบคุมเครื่องบินอัตโนมัติเป็นต้น แต่เห็นแบบนี้ระบบเช่าหนังสือออนไลน์ของเราก็จำเป็นต้องมีเหมือนกันนะครับ

• ระบบต้องตอบสนองการค้นหาข้อมูลหนังสือให้ได้ภายใน 3 วินาทีหลังจากกดปุ่ม ?ค้นหา?
• ระบบต้องรองรับ user ได้อย่างน้อย 10,000 คน
• ระบบต้องรองรับการเข้าใช้งานพร้อมกันของ user 500 คนได้
• …

Nonfunctional Requirements: Reliability and Availability

Reliability requirements ระบุถึงความเชื่อถือได้ของระบบให้เป็นตัวเลขที่วัดค่าได้ (quantified term) ที่มาของ requirement แบบนี้ก็คือความเชื่อ (ที่ถูกต้อง) ที่ว่าไม่มีระบบไหนจะสมบูรณ์แบบ 100% ดังนั้น Reliability จะระบุถึงขอบเขตของความบกพร่องที่ระบบมีอยู่ครับ เช่น ระบบเรดาห์ของสนามบินต้องทำงานผิดพลาดระดับสองได้ไม่เกิน 1 ครั้งต่อเดือนเป็นต้น แล้วระบบเช่าหนังสือออนไลน์ของเราหละ แบบนี้ดีมั้ยครับ?

• ส่วนการชำระเงินต้องทำงานผิดพลาดไม่เกิน 3 ครั้งต่อเดือน
• ส่วนการจัดส่งหนังสือต้องทำงานผิดพลาดไม่เกิน 2 ครั้งต่อเดือน
• …

Availability requirements มีความหมายใกล้เคียงกับ reliability ครับแต่มองในมุมการให้บริการกับลูกค้า ตัวอย่างง่ายๆก็ Web hosting ทั่วไปที่บอกว่าการันตี 99% up-time นั่นแหละครับ ระบบของเราก็น่าจะคล้ายๆกันครับ

Nonfunctional Requirements: Constraints

Constraints คือข้อกำหนด ข้อจำกัดหรือเงื่อนไขที่ใช้ในการออกแบบและพัฒนาระบบ Constraint มีอยู่หลายรูปแบบครับ เช่นความเที่ยงตรง (accuracy) เครื่องมือและภาษาที่ใช้ในการพัฒนาระบบ มาตรฐานการออกแบบ (Design standard) มาตรฐานในการพัฒนาระบบ มาตรฐานในการเขียนเอกสาร รวมถึงมาตรฐานของ hardware และ software ที่จะใช้ด้วยครับ ยกตัวอย่าง

• ระบบต้องเขียนด้วย jsp servlet ajax technology และมีฐานข้อมูลเป็น oracle
• ระบบต้องใช้ UML ในการออกแบบ
• การพัฒนาระบบต้องเป็นไปตามมาตรฐาน CMMi ระดับ 3
• ระบบต้องถูกติดตั้งบนเครื่อง HP ProLiant DL100
• เอกสารทุกฉบับต้องเป็นไปตามมาตรฐานของลูกค้า
• …
  

Inverse Requirements

Inverse requirements จะระบุสิ่งที่ระบบไม่ต้องทำ แปลกดีมั้ยครับ? แต่เพื่อให้การเขียน requirement ของเราสมบูรณ์เราจำเป็นต้องรู้ด้วยว่าอะไรที่ลูกค้าไม่ต้องการให้ระบบทำ เราจะได้ไม่เสียเวลาคิดตอนหลังว่า ?เอ้อ แล้วลูกค้าอยากจะได้ feature นี้มั้ยเนี่ยะ? ถ้าจะยกตัวอย่าง inverse requirement จากระบบเรา ผมคิดว่าน่าจะเป็น

• ระบบไม่ต้องดึงข้อมูลหนังสือภาษาอังกฤษ
• ระบบไม่ต้องสร้างรายงานเป็น pdf format
• ระบบไม่ต้องวิเคราะห์ข้อมูลลูกค้าเพื่อทำแผนส่งเสริมการตลาด (promotion)
• …

เอาหละครับ หลังจากเขียน D-requirements เรียบร้อยแล้ว เราจำเป็นต้องส่งเอกสารนี้ให้ลูกค้ารีวิวเพื่อทำความเข้าใจอีกครั้งก่อนจะเริ่มการออกแบบระบบอย่างละเอียดต่อไป ตรงนี้จะเป็นหน้าที่ของ Business Analyst ครับ เมื่อลูกค้าตกลงเรียบร้อย … ยังครับ ยังไม่เสร็จ

เพื่อง่ายต่อการทำงานและการสื่อสารของสมาชิกในทีม เราจำเป็นจะต้องพูดคุยกับลูกค้าอีกครั้งเพื่อจัดลำดับความสำคัญของ Requirement ที่มีในมือด้วย กระบวนการนี้เป็นหน้าที่รับผิดชอบโดยตรงของ Project Manager โดยมี Business Analyst เป็นผู้ช่วยครับ จากนั้นข้อมูลทั้งหมดที่เราได้จาก C-requirements, D-requirements และ Prioritized requirements จะต้องถูกบันทึกลงในเอกสารที่เรียกว่า Requirement Traceability Matrix ด้วย งานนี้ Project Manager รับไปครับ

ในมุมมองของผมการเขียน Requirement เป็นทั้งศาสตร์และศิลป์เพราะว่าจะเขียนเน้นไปทาง Technical จ๋าก็ไม่ได้ (ลูกค้าไม่เข้าใจ) จะเขียนแบบเป็นภาษาลูกค้าเกินไปก็ไม่ดี (ไม่ชัดเจนสำหรับ Developer) ตรงนี้จะว่าง่ายก็ง่ายจะว่ายากก็ยากครับ ตรงนี้ต้องอาศัยประสบการณ์มากพอสมควรที่จะสร้างความสมดุลตรงนี้ให้เกิดขึ้นครับ ผมเขียนบทความเกี่ยวกับเรื่องนี้ไว้ที่นี่ครับ หวังว่าจะพอช่วยให้งานของเพื่อนๆง่ายลงฮะ

เกล็ดเล็กเกล็ดน้อยอีกนิดครับ ถ้าจะให้ดีเลยนะ ใน Requirement phase เราควรจะให้ QA มีบทบาทในการคิดและออกความเห็นเกี่ยวกับ Requirement (อาจรวมไปถึง Design เบื้องต้น) ที่ได้มาจากลูกค้าด้วยครับ ที่ทำแบบนี้เพราะว่า QA จะมีมุมมองที่แตกต่างออกไปจาก Business Analyst และ Developer โดยเฉพาะอย่างยิ่งพวก Performance และ Constraints ของระบบเราครับ ตอนนี้ผมก็ใช้วิธีนี้อยู่ครับ ได้ผลดีมากๆครับ

สรุปภาคหนึ่ง

เสร็จแล้วครับ Requirement phase เหนื่อยเลย คิดซะว่าเริ่มต้นดีมีชัยไปกว่าครึ่งแล้วกันครับ ถ้าเราใช้เวลาในช่วง Requirement อย่างเต็มที่เราจะได้ข้อมูลที่ถูกต้องและครบถ้วนที่จะใช้ในการพัฒนาระบบ ความถูกต้องและความครบถ้วนนี่แหละฮะที่จะช่วยลด Requirement change ที่จะเกิดขึ้นได้ Less change – More productivity ครับ

ผมขอจบภาคหนึ่งแค่นี้ก่อนนะครับ เขียนมายาวแล้วฮะกลัวเพื่อนๆอ่านแล้วจะเบื่อไปซะก่อน แต่ไม่ต้องห่วงครับ ภาคสองที่เกี่ยวกับ Project Management – Project Planning จะตามมาติดๆครับ

ผมพยายามยกตัวอย่างการทำงานที่เกิดขึ้นจริงใน Software development project ครับ บางจุดอาจจะขาดตกบกพร่องไปบ้างเพราะข้อมูลเยอะมากจริงๆ ถ้าเพื่อนๆมีอะไรจะติชมหรือเพิ่มเติมผมยินดีมากเลย ความคิดเห็นเหล่านี้จะเป็นประโยชน์กับคนอื่นอีกมากด้วยครับ

ขอบคุณที่ติดตามผลงานมาโดยตลอดครับ

Related posts:

1. กระบวนการพัฒนาซอฟท์แวร์อย่างมืออาชีพ — ภาค2
2. กระบวนการพัฒนาซอฟท์แวร์อย่างมืออาชีพ — ภาค3
3. กระบวนการพัฒนาซอฟท์แวร์อย่างมืออาชีพ — ภาค4
4. กระบวนการพัฒนาซอฟท์แวร์อย่างมืออาชีพ — ภาค5
5. กระบวนการพัฒนาซอฟท์แวร์อย่างมืออาชีพ — ภาค6 (จบบริบูรณ์)