ทำไมระหว่างที่จอหนังในโรงภาพยนตร์จะต้องมีตัวเลขขีดๆขึ้นมาด้วย

สงสัยกันมั้ยว่าเวลาเราดูหนัง จะมีตัวเลขแปลกๆ เกิดขึ้นเสมอ เวลาดูในโรง

ผมสงสัยมานานมากๆ ละ วันนี้ได้คําตอบซักที มาดูกันเลยครับ





พี่ ตัวเลขที่คุณเห็นนั่นคือรหัสลับที่เขียนลงบนฟิล์มซึ่งแต่ละ copy จะแตกต่างกันโดยเจ้าของหนังให้ทางฟิล์มแลปเป็นคนทำรหัสลับนั้นขึ้นเพื่อตรวจ ได้ในกรณีที่มีการละเมิดลิขสิทธิ์เอาหนังไปทำแผ่นผี วีซีดีเถื่อนครับ ขยายความอีกหน่อยนะครับ คือ การละเมิดลิขสิทธิ์หนังเนี่ยมีหลายวิธีที่จะได้ตัวหนังมาหนึ่งในวิธีที่นิยม เพราะจะได้แผ่นผีออกเร็วมาก คือ การแอบเอากล้อง หรือโทรศัพท์ไปถ่ายจากหนังที่กำลังฉายในโรงหนังในกรณีที่มีการแอบถ่ายแบบนี้ เมื่อเป็นแผ่นผีซีดีเถื่อนมันก็จะมีตัวเลขรหัสลับนั้นปรากฎอยู่ในหนังแผ่นผี นั้นเมื่อเจ้าของหนังได้เห็นแผ่นผีก็จะมีการเช็คว่าตัวเลขรหัสลับที่มีตรง กับฟิล์มที่ส่งไปให้โรงหนังโรงใดจากนั้นจะได้ดำเนินการสืบว่าใครเป็นผู้แอบ ถ่าย หรือจะได้จัดการดำเนินการกับโรงหนังที่ปล่อยให้มีการแอบถ่ายหนังเรื่องนั้น เป็นผู้รับผิดชอบต่อความเสียหายที่เกิดขึ้น ในอดีต สมัย คุณ สมศักดิ์(เสี่ยเจียง) เป็นนายกสมาพันธ์มีการกำหนดบทลงโทษไว้แรงถึงขั้นสูงสุด คือถ้าโรงหนังใดปล่อยให้มีการแอบถ่ายในโรงตัวเองบ่อยๆจะให้สมาชิกสมาพันธ์ ทั้งหมด Anti ไม่ส่งหนังให้โรงนั้นฉายอีกเลยแต่ปัจจุบันไม่แน่ใจว่ามีการลงโทษใดๆ หรือไม่


ที่มา : http://movie.mthai.com/movie-guru/48497.html

มาดูความเร็วของ internet แต่ละประเทศกันครับ

สังเกต ประเทศไทยนะครับ ^^

Top Countries by Download Speed

1. 20.88 Mb/s Korea, Republic of
2. 15.75 Mb/s Japan
3. 14.59 Mb/s Aland Islands
4. 13.08 Mb/s Lithuania
5. 12.94 Mb/s Sweden
6. 12.68 Mb/s Latvia
7. 12.40 Mb/s Romania
8. 11.67 Mb/s Bulgaria
9. 11.53 Mb/s Netherlands
10. 9.54 Mb/s Moldova, Republic of
11. 9.16 Mb/s Hong Kong
12. 8.56 Mb/s Slovakia
13. 8.37 Mb/s Germany
14. 8.20 Mb/s Russian Federation

65. 2.79 Mb/s Thailand

Top Countries by Upload Speed

1. 8.83 Mb/s Lithuania
2. 7.05 Mb/s Japan
3. 5.48 Mb/s Bulgaria
4. 5.17 Mb/s Aland Islands
5. 5.06 Mb/s Latvia
6. 4.88 Mb/s Romania
7. 4.86 Mb/s Hong Kong
8. 4.64 Mb/s Russian Federation
9. 4.55 Mb/s Sweden
10. 4.37 Mb/s Slovenia
11. 3.64 Mb/s Andorra
12. 3.56 Mb/s Moldova, Republic of
13. 3.10 Mb/s Netherlands
14. 3.02 Mb/s Asia/Pacific Region

56. 0.69 Mb/s Thailand

ที่มา http://www.speedtest.net/global.php

แพทเทิร์น Agile - ปิงปองโปรแกรมมิ่ง

Agile สนับสนุนความคิดที่ว่าสองหัวดีกว่าหัวเดียว การเขียนโปรแกรมสองคนโดยใช้คอมเครื่องเดียวหรือที่เรียกว่า Pair Programming ไม่ได้ระบุว่าจะแบ่งกันเขียนโปรแกรมอย่างไร การแบ่งให้คนนึงเขียนเทสต์ อีกคนเขียนโค้ด แล้วคนเขียนโค้ดเสร็จกลับไปเขียนเทสต์ ให้อีกคนเขียนโค้ดสลับไปมาเหมือนตีปิงปอง จะทำให้งานท้าทาย ไม่น่าเบื่อ และมีประสิทธิผลมากขึ้น

แรงผลักดันทั้งแง่บวกและลบ
- คนที่อยากลอง Pair Programming ไม่รู้ว่าควรแบ่งงานกันอย่างไรดี ถ้าไม่แบ่งงานให้ดีจะกลายเป็นคนนึงพิมพ์ คนนึงเอาแต่ดู
- เขียนโปรแกรมติดกันนานๆอาจทำให้เหนื่อยล้า ปัญหาบางอันติดเป็นชั่วโมงๆถ้ามีคนช่วยดูอาจเจอวิธีแก้ปัญหาที่คนๆเดียวอาจมองข้าม
- คนเขียนโปรแกรมหรือทดสอบโปรแกรมทำงานอย่างเดียวกันทุกวันอาจนึกไม่ถึงมุมมองของอีกฝ่าย
- การผลักกันคิด ผลักกันทำ ทำให้ช่วยกันทำให้งานเดินไปอย่างต่อเนื่อง
- เขียนเทสต์ก่อนเขียนโค้ดจะไม่น่าเบื่อถ้าคนเขียนเทสต์เป็นคนละคนกับคนเขียนโค้ด

ดังนั้น

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

ข้อดี
- แต่ละฝ่ายได้มีโอกาสเขียนทั้งเทสต์และโค้ด ทำให้เพิ่มประสบการณ์ในการพัฒนากว้างขึ้น
- การสลับให้แต่ละฝ่ายจับคีย์บอร์ด จะทำให้เพิ่มความมั่นใจ และมีความเป็นเจ้าของโค้ดทีตนเขียนมากขึ้น
- การให้สองคนทำเรื่องเดียวกัน ทำให้โค้ดทุกส่วนมีแบ๊กอัพ ที่ผ่านตาอย่างน้อยสองคน ทำให้ลดปัญหาที่เกิดจากการหาคนทำแทนไม่ได้
- การมีคนช่วยคิดอยู่ข้างๆ ช่วยลดความผิดพลาด และโอกาสที่เสียเวลานานๆกับการติดปัญหาที่เขียนโปรแกรมคนเดียวมักมองไม่ออก
- การสลับคู่เขียนโปรแกรมในทีม ทำให้ทุกคนในทีมมีโอกาสทำงานร่วมกัน และทำให้แต่ละคนได้มีโอกาสเรียนรู้งาน เห็นภาพรวมของทั้งระบบ จะมีส่วนช่วยให้เข้าใจจุดประสงค์ของการเขียนงานส่วนย่อยแต่ละส่วนมากขึ้น
- การใช้หลักปิงปอง ทำให้รู้สึกสนุกขึ้น ต่างฝ่ายต่างพยายามท้าทายอีกฝ่าย
- ใช้หลักนี้ ในการอบรมนักพัฒนาที่มีประสบการณ์น้อยกว่าได้ โดยคนที่มีประสบการณ์มากกว่าสามารถเขียนโค้ดและอธิบายสิ่งที่ตนทำ ในขณะเดียวกันคนที่มีประสบการณ์น้อยกว่าก็สามารถลองหัดโดยมีพี่เลี้ยงคอยแนะ เพิ่ม
- ลดความเหนื่อยล้าจากการทำอะไรอย่างใดอย่างหนึ่งติดกันนานมากๆ เมื่อฝ่ายใดฝ่ายหนึ่งที่ถือคีย์บอร์ดเริ่มหมดสมาธิ ก็สามารถสลับให้อีกฝ่ายทำต่อ
- ในระหว่างที่คนหนึ่งเขียนโปรแกรม อีกฝ่ายสามารถคิดวิธี refactor โค้ดให้กระทัดรัด อ่านง่าย และสื่อความหมายดีขึ้น ทำให้เราสามารถปรับปรุงคุณภาพโค้ดให้ดีขึ้นได้ทันที

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

เทคนิคในทางปฏิบัติ
การ เขียนโปรแกรมแบบปิงปอง จะได้ผลดีเมื่อเราใช้แนวการพัฒนาโปรแกรมโดยการเขียนเทสต์ก่อน (test driven design) โดยคนหนึ่งเขียนเทสต์ให้อีกคนเขียนโค้ดเพื่อรันเทสต์ให้ผ่าน การเขียนเทสต์เหมือนกับการกำหนดอินเตอร์เฟซว่าเราจะต้อง Implement อะไรบ้าง และเป็นการทำให้รู้ว่าควรเขียนโค้ดอย่างไรให้รันเทสต์ผ่าน ไม่ควรเขียนโค้ดเผื่อสิ่งที่ไม่ได้เขียนเทสต์ครอบคลุมไว้ และพยายาม refactor โค้ดเมื่อเห็นโอกาส

การเขียนโปรแกรมสองคน ทุกคนควรมีโอกาสเขียนร่วมกับคนอื่นๆในทีม โดยอาจกำหนดตารางทำงานสลับคู่ทุกวัน อย่าง pairing matrix หรือ pairing calendar เพื่อให้ทุกคนมีโอกาสทำงานร่วมกันคนอื่น มีโอกาสเรียนรู้งานส่วนอื่นๆ และทำให้ทีมมีความสัมพันธ์ดีขึ้น บางองค์กรอาจเขียนโปรแกรมสองคนตลอดทั้งวันและทุกๆวัน ในขณะที่บางองค์กรอาจแบ่งเวลาครึ่งวันเขียนโปรแกรมร่วมกัน และอีกครึ่งวันแยกเขียนตามปกติ เพื่อจะได้มีเวลาเช็คอีเมล์หรือเคลียร์งานด้านอื่นๆ

แพทเทิร์นที่เกี่ยวข้อง
Agile แบ่งงานออกเป็นเรื่องๆ (User story) ที่มีขอบเขตเนื้อหาสำหรับเขียนไม่มากนัก เช่นใช้เวลาในหน่วยวันสองวัน การใช้โปรแกรมมิ่งแบบปิงปองเป็นรูปแบบหนึ่งของการเขียนโปรแกรมทีละสองคน และสนับสนุนให้เขียนโปรแกรมโดยการเขียนเทสต์ก่อน การเขียนเทสต์ควรใช้ไลบรารี่อย่าง unit testing, mock objects ร่วมกับ continuous integration tool การเขียนโค้ดควรต้องมี IDE ที่สนับสนุน Refactoring, version control

ที่มา http://www.thaidev.org/?p=70

แพทเทิร์น Agile – ยืนประชุมประจำวัน

"คนเรายืนนานๆแล้วเมื่อย ถ้าต้องยืนประชุมจะได้ไม่เยิ่นเยื้อ หาข้อสรุปได้เร็วๆไม่เสียเวลาทุกคน"

Agile เน้นการสื่อสารบ่อยๆ นั่นหมายถึงแต่ละวันสมาชิกในทีมควรมีเวลาเล่าให้คนอื่นฟังถึงความคืบหน้าและ ปัญหาที่ติดที่คนอื่นอาจช่วยได้ ให้ทุกคนฟัง แต่ทำยังไงให้ประชุมไม่ยืดเยื้อ จนเสียเวลาทำงาน หรือนานจนหมดสมาธิ

แรงผลักดันทั้งแง่บวกและลบ
- การสื่อสารระหว่างสมาชิกในทีมเป็นสิ่งสำคัญ สมาชิกในทีมควรรู้ถึงความคืบหน้าของโครงการโดยรวมจากสิ่งที่สมาชิกแต่ละคนทำอยู่
- เวลาเป็นของมีค่า ทีมพัฒนาควรใช้เวลาส่วนใหญ่วางแผน ออกแบบ เขียน และทดสอบโปรแกรม ถ้าต้องเสียเวลาประชุมบ่อยๆครั้งละนานๆคงไม่เหมาะ
- การได้เล่าถึงปัญหาที่เราติดอยู่ อาจมีคนอื่นรู้วิธีแก้ปัญหาสามารถช่วยเหลือได้
- การประชุมสำหรับทีมที่มีสมาชิกมากๆ มักยืดเยื้อ และฟังดูเป็นทางการ
- ประชุมสั้นไป อาจทำให้ได้ข้อมูลไม่ละเอียดพอที่ทุกคนจะเข้าใจตรงกัน

ดังนั้น

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

ประโยชน์
- ประชุมรายวัน ช่วยการสื่อสารข่าวสารในทีมให้ทันเหตุการณ์
- ปัญหาที่เราเล่าให้ทีมฟัง อาจมีคนเคยเจอและรู้วิธีแก้ ทำให้เราไม่ต้องเสียเวลาค้นวิธีแก้ปัญหาเอง
- ทุกคนรู้ว่่าถ้าประชุมนาน จะต้องยืนจนเมื่อย ทำให้ตัดสินใจว่าเรื่องไหนควรคุยต่างหาก เรื่องไหนที่ต้องรีบตัดสินใจ เรื่องไหนควรคุยนอกรอบ
- การได้ฟังตัวอย่างดีๆจากความคืบหน้าของผู้อื่น ทำให้เราอยากมีผลงานให้เทียบเท่าหรือทำให้ดียิ่งขึ้น
- การยืนประชุมไม่เหมาะสำหรับทุกเรื่อง เรื่องที่ต้องใช้เวลานาน ควรใช้วิธีการประชุมแบบปกติ
- ถ้าจัดประชุมตอนเช้า เป็นการลดปัญหาคนมาทำงานสายไปในตัว

เทคนิคในทางปฏิบัติ

Agile พยายามหลีกเลี่ยงอะไรที่เป็นทางการ แต่ในขณะเดียวกันวิธีนี้จะประสบความสำเร็จเมื่อทุกคนต้องมีวินัยมีความรับ ผิดชอบสูง การประชุมที่ใช้เวลาสั้นๆจึงสำคัญมากที่ทุกคนต้องตรงเวลา การยืนประชุมครั้งแรก อาจต้องมีคนแนะนำถึงขั้นตอน ส่วนใหญ่สมาชิกจะยืนล้อมเป็นวงในพื้นที่ว่างๆที่ใกล้จุดที่สมาชิกส่วนใหญ่ทำ งาน ไม่จำเป็นต้องจัดในห้องประชุม เพื่อลดความเป็นทางการลง ถ้าทีมมีการใช้ฝาผนังเก็บข้อมูลโครงการ เช่น story card, burnup chart ก็ควรประชุมใกล้ๆฝาผนังเพื่อจะได้ง่ายต่อการอ้างอิงถึงข้อมูลบนฝาผนัง ถ้าการประชุมนอกห้องประชุมส่งเสียงดังรบกวนทีมอื่นจริงๆ ค่อยย้ายไปที่ห้องประชุม

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

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

ทีมที่มีขนาดใหญ่มากๆอาจมีปัญหาในการควบคุมเวลาและหาสถานที่ที่ใหญ่พอที่ ทุกคนจะยืนประชุมได้ และทำให้ฟังลำบากถ้าคนพูดอยู่ไกลและพูดเสียงเบา ปัญหานี้ไม่ควรมีเพราะ agile ไม่ส่งเสริมให้ทีมมีขนาดใหญ่เกินไป สิบคนน่าจะเป็นจำนวนสูงสุดของทีม ถ้าทีมไหนมีสามาชิกเกิน ควรแบ่งออกเป็นทีมย่อย โดยแต่ละทีมอาจให้ผู้จัดการทีม เป็นผู้ประสานงานข้ามทีมย่อย

แพทเทิร์นที่เกี่ยวข้อง
การยืนประชุมเป็นส่วนหนึ่งของกิจกรรมสำคัญของทีม Agile โดยเล่าถึงความคืบหน้าจากแผนที่่วางจาก การประชุมการวางแผนระดับ Iteration โดยแต่ละคนจะรายงานถึงความคืบหน้าของ Story card ที่ตนทำอยู่

ที่มา http://www.thaidev.org/?p=68

ความแตกต่างระหว่าง Software Engineer กับ SA

นึกสนใจก็เลยลองเสาะหาข้อมูลมาซะหน่อย

ถ้ามอง ปัจจัยในการ พัฒนา Software เป็นหลักนะครับ
SA ==> System Analyst จะเป็น ผู้ที่ทำการวิเคราะระบบเป็นหลัก ซึ่งจะ Abstarct มากๆ ก่อน
SE ==> System Engineer นำสิ่งที่ SA วิเคราะห์มา ในเชิง Realize ขึ้น คือเริ่มมองเห็นรูปร่างของ Software นั่นเองครับ
SAt ==> System architecture เป็นคนออกแบบโครงสร้างของระบบทั้งหมดในเชิง Software คือ ระบุได้ว่า ส่วนไหนพัฒนางานโดยอะไร (Framwork ใด) รูปแบบไหน


Software Engineer จะดูแลเรื่อง Detail Design เช่น การ Design Class Diagram และ Sequence Diagram นอกจากนี้ถ้าเป็น SE ระดับ Senior หน่อยก็เป็นพวก Project Management ครับ ส่วน System Analyst จะดูเรื่องการเก็บ Requirement ทำพวก Input และ Output ที่ User ต้องการ รวมถึง Business Process ต่างๆ ส่วน System Architect จะดูและภาพรวมของระบบ Environment ของระบบ การ Integrate เข้ากับระบบอื่น

ซึ่ง ถ้าเคยเรียน Software Engineering จะเห็นได้ว่าวิชาจะเน้นหนักไปที่ Software Lifecycle, Project Management , Software Quality และ Design Pattern

System Analysis จะเน้นพวกการเก็บ Requirement การกำหนด Input Output การ Design Process Flow

System Architect ซึ่งยังไม่ค่อยมีเปิดสอน จะเน้นพวก System Integration และความรู้ด้าน Data Communication ครับผม

SA ที่หมายถึง System Analyst ยังสามารถแบ่งออกเป็น 2 ประเภทอะครับ (อ้างอิงจากที่เคยเรียนอะนะ)

1.) System Analyst
2.) Bussiness Analyst

ถ้า เป็นลักษณะที่ 1. ก็รู้ Business และเข้าใจ Requirement ในระดับที่สามารถออกแบบระบบ หรือ ส่วนใหญ่กระบวนทางธุรกิจก็มักจะหมายถึง Table ใน Database รวมไปถึงสามารถอธิบาย Business Flow ให้พวก Developer ทำโปรแกรมออกมาให้ตาม Requirement ของลูกค้า
เข้าใจว่างานหลักๆคือเน้น การสร้างระบบจึงต้องมีความรู้ด้าน Program ด้วย ไม่อย่างนั้นจะคุยกะโปรแกรมเมอร์ไม่ค่อยรู้เรื่องเหมือนพูดกันคนละภาษา
แต่คนพวกนี้จึงอาจโดนเกณฑ์ไป coding ถ้าโปรเจคไม่เสร็จ

ถ้า เป็นลักษณะที่ 2. เข้าใจว่าต้องเป็นพวกที่มีประสบการณ์ด้าน Business สูง สามารถวิเคราะห์ข้อมูลหรือ Requirement จากลูกค้าได้ พวกนี้อาจจะต้องหนักด้านการติดต่อกับลูกค้าเป็นหลัก , design table , หน้าจอ เข้าใจ flow งานทั้งหมดแต่อาจจะไม่ต้อง Programming เป็นเลยก็ได้

แต่ ในโลกตวามจริง โปรเจคอาจจะไม่จำเป็นต้องจ้าง SA ที่เป็น 2 แบบนี้พร้อมกันเพราะทำให้ต้นทุนสูงก็เลยจ้างมาคนเดียวแล้วก็รับหน้าที่ทั้ง 2 เรื่องนี้ไปพร้อมๆกัน เพราะ Phase Design มันไม่ได้ต้องทำกันตลอดทั้ง Project และเมื่อ SA วางระบบเสร็จแล้ว ขั้นตอนในการ implement หรือ tuning ระบบให้เข้ากับความต้องการ SA ก็ไม่ต้องทำงานหนักแล้วดังนั้นความรับผิดชอบก็จะตกอยู่ที่การไปคุยกับลูกค้า ว่าระบบโ
อเคไม๊มมากกว่า

อีกอย่างนึงที่มักจะเห็น SA ชอบทำตกไปคือ การให้ความเข้าใจกับลูกค้า SA ควรจะ minimize scope ของงานให้ได้ตาม requirement แต่ไม่ได้ทำให้งานไปตกอยู่ที่ Programmer ทั้งหมด ดังนั้นในขั้นตอนการ design จึงเป็นเรื่องสำคัญว่าจะทำอย่างไรให้ระบบทำงานได้ครบตามความต้องการ และ งานไม่ใหญ่มากนักเพื่อให้ส่งมอบงานได้ตรงเวลาอะครับ (ไม่งั้นอาจเห็น Programmer กับ SA ทะเลาะกันแน่ๆ)


ส่วน SA ที่เป็น Software/System Architect

เน้นหนักไปที่การ design software / system ให้มี Quality หรือ Best Performance มากกว่าอะครับ แช่นทำอย่างไรโปรแกรมจะทำงานได้เร็ว , โปรแกรมไม่ Error บ่อย , ปรับระบบให้รองรับต่อการเปลี่ยนแปลง ต้องเข้าใจก่อนนะครับว่าในส่วนของ Architect นี้ไม่ได้เกี่ยวข้องกับ Requirement เพราะ Analyst เป็นคน design ให้ตรงกับ Requirement
ดัง นั้นคิดว่าคนเป็น Architect ควรจะมีความรู้ด้าน Design Pattern , Framework เป็นอย่างดี และสามารถประยุกต์เข้ากับระบบที่ Analyst design มา

Requirement แบ่งออกเป็น 2 ส่วน คือ

functional requirement : Analyst ต้องรับตรงนี้ไปหละว่าจะ design กันยังไง

non-function requirement : ตรงนี้ Architect ต้องดูแล

หากความรู้อันน้อยนิดที่ผมกล่าวนั้นบกพร่องก็ขออภัยด้วยนะครับ และก็ขอให้ผู้รู้วานช่วยแก้ไขด้วยละกันครับ

ที่มา http://www.narisa.com/forums/index.php?showtopic=3968