วันจันทร์ที่ 16 กุมภาพันธ์ พ.ศ. 2552

Software Park Thailand Training Program :: Managing Non-Functional Requirements and Business Goals

Date / Time : 16 - 18 February 2009
Venue : Training / Seminar Room, 3rd Floor, Software Park Building
Registration Fee : 12,840 Baht (Included VAT 7 %)

Court Overview:
การจัดการความต้องการ หรือ Requirements Management ในปัจจุบันถือว่าเป็นปัญหาในขั้นวิกฤต เนื่องจากเป็นขั้นตอนที่สำคัญมาก เพราะเป็นขั้นตอนแรก ๆ เพื่อทำความเข้าใจกับความต้องการก่อนที่จะนำผลการวิเคราะห์ความต้องการไป วิเคราะห์และออกแบบระบบฯ และ เข้าสู่ขั้นตอนต่อไป ๆ ตามกระบวนการพัฒนาซอฟต์แวร์ ดังนั้นเห็นได้ว่าหากขั้นตอนแรกนี้ผิดพลาดจะมีโอกาสสูงที่จะส่งผลกระทบต่อ ขั้นตอน ต่อไป ๆ ได้ โดยผลกระทบที่ตามมาอาจเต็มไปด้วย ค่าใช้จ่าย กำลังคน เวลา และทรัพยากร
ปัญหาในการทำ Requirements Management ในปัจจุบันคือมีการใช้องค์ความรู้แบบเก่า ซึ่งไม่มีประสิทธิภาพและทันต่อการเปลี่ยนแปลงของเทคโนโลยีและกระบวนการพัฒนา ซอฟต์แวร์สมัยใหม่ และการทำ Requirements Management แบบดั้งเดิมมักไม่ให้ความ สำคัญกับสิ่งสำคัญอื่นมากมาย เช่น
- ความต้องการหรือเป้าหมายทางธุรกิจ (Business Goals)
- ความต้องการประเภท Non-Functional Requirements ซึ่งมักส่งผลกระทบต่อคุณภาพและความเสี่ยงมากยิ่งกว่า Functional Requirements
- คุณภาพของสถาปัตยกรรมซอฟต์แวร์และระบบฯ
- ภาษาและการสื่อสาร
- การเจรจาต่อรอง
- การลดข้อขัดแย้งระหว่างการประชุม
- การจัดการการเปลี่ยนแปลง
- ความเข้าใจในภาคธุรกิจและโมเดลธุรกิจ
- ปัญหาการเมืองภายในและระหว่างองค์กร และปัญหาคอร์รัปชั่น
- การตัดสินใจ
- การเงินและการประมาณการเบื้องต้น
- การวิจัยตลาด เช่น การทำแบบสำรวจ การรวบรวมความต้องการจากแหล่งข้อมูลต่าง ๆ
- กระบวนการพัฒนาซอฟต์แวร์สมัยใหม่ เช่น RUP, CMMI, Agile เช่น Extreme Programming, Scrum
- หลักการพัฒนาซอฟต์แวร์สมัยใหม่ เช่น Object-Oriented Programming
- การใช้ UML (Unified Modeling Language)
- การอธิบายความต้องการให้อยู่ในรูปแบบของ Software Definition
- ฯลฯ
นอกจานี้ ปัญหาในการจัดการ Requirements ในแบบที่ผิดมักเน้นหนักที่การจัดการ Functional Requirements แต่ในความเป็นจริง ปัจจัยที่จะส่งผลกระทบต่อสถาปัตยกรรมซอฟต์แวร์และระบบฯ คือ Non-Functional Requirements และ Business Requirements หรือ Business Goals ซึ่ง Requirements สองประเภทนี้หากจัดการผิดพลาด จะส่งผลต่อคุณภาพของสถาปัตยกรรมซอฟต์แวร์และระบบฯ ทำให้ เกิดความเสี่ยงในด้านค่าใช้จ่าย กำลังคน เวลา ทรัพยากรมากมาย
หลักสูตรนี้ เน้นถึงการทำความเข้าใจกับความต้องการประเภท Non-Functional Requirements และ Business Requirements หรือ Business Goals โดยผู้เข้ารับการอบรมจะสามารถกำหนด, จัดกลุ่ม, วิเคราะห์ และจัดการได้อย่างมีประสิทธิภาพเพื่อให้ระบบฯ ที่จะพัฒนามีคุณภาพ คุ้มค่า และเกิดประโยชน์สูงสุด และนอกจากนี้ผู้เข้ารับการอบรมจะเข้าใจถึงการจัดการด้านคุณภาพโดยมีกรอบของ Non-Functional Requirements และ Business Requirements หรือ Business Goals เป็นดัชนีชี้วัด (KPI) และผู้เข้ารับการอบรมจะได้เรียนรู้และเข้าใจในทักษะที่เป็น Soft Skill อีกมากมาย

Course Audience:
คอร์สนี้เหมาะสำหรับ System Analyst, Business Analyst, (Software) Sales Specialist, IT Manager / CIO / CTO, Software Architect, Programmer, นักเรียน / นักศึกษา และผู้สนใจทั่วไปในการพัฒนาซอฟต์แวร์
พื้นฐานของผู้เข้ารับการอบรม (Prerequisites)
ผู้เข้ารับการอบรมควรมีความรู้ด้านกระบวนการพัฒนาซอฟต์แวร์มาก่อน

Course Contents:
- ปัญหาการทำ Requirements Management ในปัจจุบัน
- ความสำคัญและหลักการทำ Requirements Management เบื้องต้น
- สถาปัตยกรรมซอฟต์แวร์ (Software Architecture) เบื้องต้น
- วงจรการตอบสนองซึ่งกันและกันของธุรกิจและสถาปัตยกรรม (Architectural Business Cycle)
- การกำหนดผู้ที่มีผลต่อความสำเร็จหรือล้มเหลวของโครงการ (Stakeholder), ผู้นำและผู้สนับสนุนทีม (Champion) และผู้เชี่ยวชาญเฉพาะด้าน (Domain Expert)
- กระบวนการพัฒนาซอฟต์แวร์แบบวนซ้ำ (Iterative and Incremental Development) สำหรับกระบวนการพัฒนาซอฟต์แวร์สมัยใหม่
- ปรัชญา Agile เพื่อการพัฒนาซอฟต์แวร์ที่กระชับ รวดเร็ว เรียบง่าย ความเสี่ยงต่ำ และสร้างความพึงพอใจของลูกค้า (Customer Satisfaction) สูงสุด
- ช่วงการทำสถาปัตยกรรมซอฟต์แวร์ ในกระบวนการพัฒนาซอฟต์แวร์ (Architecture In The Life Cycle)
- คุณสมบัติ บทบาท หน้าที่รับผิดชอบ และทีมในการดำเนินการ
- ความสำคัญและหลักการของ Business Modeling และ การวิเคราะห์ Business Model
- การแบ่งประเภทระหว่าง Functional Requirements, Non-Functional Requirements และ Business Goals หรือ Business Requirements
- ความสำคัญและผลกระทบของ Non-Functional Requirements และ Business Requirements หรือ Business Goals ที่มีต่อสถาปัตยกรรม ซอฟต์แวร์และระบบฯ
- เทคนิควิเคราะห์ปัญหา
- การระบุความต้องการเชิงธุรกิจ (Business Goals / Requirements / Stakeholder Needs) และการวิเคราะห์จาก Vision Document หรือ Operational Concepts Document (OCD) หรือ แผนธุรกิจ (Business Plan)
- ทำความเข้าใจกับคุณสมบัติเชิงคุณภาพ (Quality Attributes) และการกำหนด Non-Functional Requirements และ Business Goals เช่น Availability, Modifiability, Scalability, Security, Performance, Interoperability, Integrability, Testability, Usability, Reliability, Short Time to Market, Less Cost, Neat Feature, Competitiveness ฯลฯ
- การกำหนดคุณสมบัติด้านคุณภาพ (Quality Attributes) ของสถาปัตยกรรมซอฟต์แวร์และระบบฯ
- การทำความเข้าใจกับความต้องการต้องของลูกค้าและผู้ใช้ ที่อาจไม่ได้บอกตรง ๆ
- การลดข้อขัดแย้ง และจัดการการสื่อสารกับลูกค้า
- เทคนิคการสัมภาษณ์ การตั้งคำถาม จิตวิทยาการสื่อสาร การทำแบบสอบถาม เพื่อรวบรวมและค้นหา Non-Functional Requirements และ Business Requirements หรือ Business Goals แท้จริง หรือ ซ่อนอยู่ หรือถูกปกปิด
- การทำเวิร์คช็อป เพื่อให้วิสัยทัศน์และความต้องการเป็นไปในทิศทางเดียวกัน
- การค้นหาและรับมือกับปัญหาการเมืองภายในและระหว่างองค์กร และการคอร์รัปชั่น
- การเขียน Use Case Model และการวิเคราะห์ Use Case
- เทคนิคใหม่ในการระบุความต้องการด้วยการเขียน Storyboard และ Scenario โดยมีการประยุกต์ UML ด้วยเพื่อจำลองเหตุการณ์ที่สอดคล้อง กับความต้องการ
- การกำหนดนิยาม (Definition)
- การกำหนดคุณสมบัติของความต้องการ (Requirement Attributes) และการทำ Requirement Matrix
- การวัดผลและประเมิน (Requirements Measurement), การกำหนดตัวขับเคลื่อนกระบวนการทางสถาปัตยกรรม (Architectural Drivers) และทำความเข้าใจกับ Use Case ที่มีผลต่อสถาปัตยกรรมซอฟต์แวร์และระบบฯ (Architecturally Significant Use Cases)
- การกำหนดและจัดการขอบเขตของระบบที่จะพัฒนา และ Requirements ที่มีผลต่อสถาปัตยกรรมซอฟต์แวร์และระบบฯ
- การจัดการเอกสาร Requirements ต่าง ๆ เช่น Requirements Specification, Use Case Specification / User Story เป็นต้น
- การตรวจสอบย้อนกลับ (Traceability) เพื่อให้ระบบฯ ถูกต้องตามความต้องการและตรวจสอบแก้ไขได้ง่ายและสะดวก
- การ Transform จาก Requirements สู่ Implementation และทำความเข้าใจกับ The Level of Abstraction และกระบวนการ Realization
- ทำความเข้าใจกับ Verification และ Validation
- การจัดการร่วมกับการจัดการการเปลี่ยนแปลง (Change Management)

Course Benefits:
ในการอบรมนี้ผู้เข้ารับการอบรมจะได้เข้าใจการออกแบบและวิเคราะห์ สถาปัตยกรรมซอฟต์แวร์โดยละเอียด หลังจากการอบรมนี้ ผู้เข้ารับการอบรมจะมีความเข้าใจที่ดีขึ้นในเรื่อง:
- หลักการพิจารณาที่สำคัญในกระบวนการออกแบบสถาปัตยกรรม
- Patterns ทางด้านสถาปัตยกรรมซอฟต์แวร์และความสัมพันธ์กับคุณภาพของระบบ
- รวบรวมคุณสมบัติด้านคุณภาพระบบที่สำคัญโดยทำ Quality Attribute Workshop
- วิธีการออกแบบสถาปัตยกรรมโดยใช้วิธี Attribute-driven Design (ADD)
- การใช้วิธีต่าง ๆ ในวงรอบการพัฒนาซอฟต์แวร์ (Software Development Life Cycle)
- บทบาทและการประเมินสถาปัตยกรรมซอฟต์แวร์
- การ Reuse ทางด้านสถาปัตยกรรมซอฟต์แวร์

ไม่มีความคิดเห็น:

แสดงความคิดเห็น