ผมไม่ค่อยเข้าใจเกี่ยวกับ Software Engineer ช่วยอธิบายหน่อยคับ

ของต่างประเทศไม่รู้

iStyle Sun, 13/02/2011 - 17:19

ของต่างประเทศไม่รู้ แต่ผมว่าของไทยต้องเป็นคนคุยกับลูกค้าด้วยแหละครับ แบบต้องการโปรแกมลักษณะไหน วางแผนโปรเจคด้วย(เป็นโปรเจคแมนเนเจอร์) งานมันก็คาบๆ กันอยู่

(จากที่เรียนมา)

ในต่างประเทศผมก็ไม่รู้เช่นกัน แต่ในไทย Software En. เป็นแค่วิชาหนึ่งใน Com En. กับ Com Sci อ่ะคับ เรียนไปเพื่อให้รู้ถึงปัญหาของการออกแบบ Software การควบคุมโครงการพัฒนา software การคิดมูลค่าของ software แล้วก็พวกการยกระดับการพัฒนาพวก CMMI ขั้นพื้นฐานอ่ะคับ
ผมก็รู้ไม่มากเท่าไหร่ ผิดถูกยังไง เดี๋ยวคงมีคนรู้จริงมาอธิบายต่อไปครับ

+1 ครับ เพิ่มเติมอีกนิด คือ

ytheafter Sun, 13/02/2011 - 22:54

+1 ครับ
เพิ่มเติมอีกนิด คือ เรียนรู้เกี่ยวกับ life cycle ของ software
software ก้อมีวันหมดอายุ ดังนั้นจึงต้องมีการออกแบบ วางแผน ประเมิน software
เลือกใช้เทคโนโลยีที่ดี ควบคุมมาตรฐานของ software ให้มีประสิทธิภาพ
ปัจจุบันมีดัชนีชี้วัดมาตรฐานแบ่งไปตาม CMMI Level ครับ

จากที่รู้มาป.ตรีในไทยไม่มีที่

Kiss Sun, 13/02/2011 - 20:51

จากที่รู้มาป.ตรีในไทยไม่มีที่ไหนเปิดสอนสาขาSoftware Engineer
มีแต่เรียนวิชาของ Software Engineer ทั้ง Com En.,Com Sci และ IT
ฉนั้นเท่าที่เคยเรียนมา SoftwareEn. ไม่จำเป็นต้องเขียนโค๊ดเก่ง ไม่จำเป็นต้องพูดเก่ง แต่ต้องออกแบบและแก้ไขโครงสร้างและส่งต่อให้โปรแกรมเมอร์โดยที่ผิดพลาดน้อยที่สุด

มีครับอย่างน้อยก็ มช.

iStyle Sun, 13/02/2011 - 20:59

มีครับอย่างน้อยก็ มช. ของจุฬาพึ่งโดนยุบไป(ปี 3 ปีนี้เป็ยรุ่นสุดท้าย)

KU มีครับ หลักสูตร SKE

lancaster Sun, 13/02/2011 - 21:42

KU มีครับ หลักสูตร SKE

ที่ ม แม่ฟ้าหลวง ก็มีครับ

gusevoisadd Sun, 13/02/2011 - 22:05

ที่ ม แม่ฟ้าหลวง ก็มีครับ เรียนอยู่ครับ ^_^ อากาศดีๆ ดูหมอกยามเช้าๆทุกวัน หุหุ ถ้าอยากรู้ว่ามาเรียนที่นี่แล้ว จะต้องเจอกับวิชาอะไร กดลิ้งเลยครับ http://bit.ly/dHeweR แต่อาจจะยังไม่ครบทุกวิชาน้ะครับ เพราะสำหรับเด็กใหม่ ได้มีการปรับปรุงหลักสูตร ตามนโยบายของมหาวิทยาลัย

ปล.ที่นี่ เรียนเป็นภาษาอังกฤษทุกสาขาวิชา (ยกเว้น นิติศาสตร์) แต่ไม่ใช่หลักสูตรอินเตอร์น้ะครับ

กบจริงนะเรา T T

Kiss Mon, 14/02/2011 - 09:58

กบจริงนะเรา T T

ตามข้างบนเลยคับ

By_Myself Sun, 13/02/2011 - 21:10

ตามข้างบนเลยคับ ผมมาหาข้อมูลก่อนจะเลือกจะไปเรียนที่มช.คับ
แล้วทำไมที่จุฬาโดนยุบละนั้น ชักเสียวๆละนั้น -*-

มันไม่ฮิตน่ะครับ

iStyle Sun, 13/02/2011 - 21:50

มันไม่ฮิตน่ะครับ ที่สำคัญมันเรียนแยก ไปเรียนที่น่าน.. เหตุผลอื่นไม่รู้

CAMT ผมก็เรียนอยู่

NGFar Sun, 13/02/2011 - 22:56

CAMT ผมก็เรียนอยู่ แต่สาขาแอนนิเมชันอ่ะ

ลองดูครับ อันนี้ของเกษตร

GateKung Sun, 13/02/2011 - 21:41

ลองดูครับ อันนี้ของเกษตร http://iup.eng.ku.ac.th/se.php

Software Engineering

lew Sun, 13/02/2011 - 22:33

Software Engineering นี่ผมเรียกว่าศาสตร์แห่งการ "ผลิต" ซอฟต์แวร์ครับ

ต้องเข้าใจก่อนว่ามันไม่ใช่การเรียน "เขียนโปรแกรม" เพียงอย่างเดียว หัวใจของ Software Engineering คือการ "ทำซ้ำได้" ครับ ถ้าเราบอกว่าเราเขียนโปรแกรมบัญชีให้กับบริษัท A แล้วความซับซ้อนประมาณหนึ่ง เขียนเสร็จแล้วไปทำใหม่ให้กับบริษัท B ที่ความซับซ้อนเท่า ก็ควรใช้เวลาเท่ากันหรือน้อยกว่า ภายใต้คุณภาพที่เท่าเทียมกัน

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

จะบอกได้อย่างไรว่าซอฟต์แวร์ที่ว่าซับซ้อน "พอๆ กัน" หรือซับซ้อนกว่า หรือง่ายกว่า?
จะบอกได้อย่างไรว่าซอฟต์แวร์ที่ผลิตมามีคุณภาพเท่าเทียมกันดีกว่า แย่กว่า?
จะบอกได้ประเมินอย่างไรว่าเราต้องใช้เวลาเท่าใหร่ในการพัฒนา เราต้องใช้คนกี่คน?

เรื่องที่เรียนใน Software Engineering จึงไม่ใช่แค่การเรียนเขียนโปรแกรมครับ มันรวมไปถึงการแบ่งงาน, การจัดการ, การทดสอบ, ฯลฯ

มันคือแนวคิดการทำงานตามหลักวิ

netfirms Sun, 13/02/2011 - 23:06

มันคือแนวคิดการทำงานตามหลักวิศวกรรมเพื่อให้ซอฟท์แวร์ที่ผลิตออกมามีมาตรฐานน่ะครับ

สำหรับผม

Sxton Mon, 14/02/2011 - 00:08

สำหรับผม แปลตรงตัวเลยครับมันก็คือ "วิศวกรรมซอฟท์แวร์"

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

เช่นเดียวกันกับซอฟแวร์ ถ้าเอาใกล้ๆตัวก็ซอฟแวร์เกมครับ
การจะสร้างเกม 1 เกมก็ใช่ว่าจะต้องมานั่งโค้ดกันตั้งแต่ระบายสีลงบนจอทีละจุด เดี๋ยวนี้เค้ามี API
หรือ Engine ให้ใช้กันแทบทุกส่วนไม่ว่าจะเป็น Graphic, AI, 3D, Physic, Network
หรือ Game Engine ที่แค่เคาะโค้ดไม่กี่บรรทัด ใส่ภาพสวยๆเข้าไปแล้วออกมาเป็นเกมได้ก็ยัังมี

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

เห็นด้วย +1 ศาสตร์ของ

piscessera Mon, 14/02/2011 - 01:13

เห็นด้วย +1
ศาสตร์ของ Software Engineering เกิดมาเนื่องจากเหตุการณ์ Software Crisis หรือแปลตรงตัวก็คือ วิกิตการณ์ซอฟต์แวร์ ซึ่งเป็นเหตุการณ์ที่บริษัทพัฒนาซอฟต์แวร์มากมายพัฒนาโปรแกรมขึ้นมาได้อย่างไม่มีคุณภาพ โปรแกรมเสร็จจริง แต่มีปัญหาใช้ไม่ได้ มีข้อผิดพลาดมากมาย ดังนั้นเพื่อให้เกิดคุณภาพจึงได้มีการนำหลักการของ Engineering ซึ่งมีทั้งการหลักการของการวิเคราะห์และออกแบบเข้ามาประยุกต์กับ Software จึงทำให้เกิดศาสตร์ทางด้าน Software Engineering ขึ้นมา

ผมมองงี้ครับ Software

mr_tawan Mon, 14/02/2011 - 00:44

ผมมองงี้ครับ

Software Engineer เป็นตำแหน่ง (Job Position)
Programmer หรือ Tester เป็นบทบาท (Roles)

เหมือนที่คุณ lew บอก SE

piscessera Mon, 14/02/2011 - 01:18

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

ถ้ายกตัวอย่างง่ายๆ ก็ตามหลักการ Software Development Life Cycle (SDLC) เช่น Waterfall Model ซึ่งเป็นขั้นตอนการพัฒนาโครงการที่ปัจจุบันใช้กันค่อนข้างเยอะ (น่าจะใช้เยอะเพราะมันเป็นไปตามธรรมชาติของการพัฒนา ตามความคิดของผมนะ) โดยตัวโมเดลจะเริ่มที่ Requirements -> Design -> Implementation -> Verification -> Maintenance ครับ (ตัวนี้เหมือนจะเป็น Waterfall แบบเก่าคือทำเสร็จเป็นเรื่องๆ ไป แต่แบบใหม่จะสามารถทำย้อนกลับได้ด้วย คือหากกำลังทำ Design อยู่แล้วพบว่าผิดพลาดไม่ตรงตาม Requirement ก็จะไปทำส่วนของ Requirements ใหม่)

Planing คือช่วงเกิดเริ่มขั้นตอนของ Requirements ซึ่งจะเป็นส่วนของ Project Management โดยจะเป็นการวางแผนเกี่ยวกับโครงการทั้งหมดว่าใช้ระยะเวลาเท่าไร จะใช้ทรัพยากรอย่างไร จะจัดสรรยังไง
Requirements คือส่วนของการไปเก็บความต้องการของลูกค้าว่าเค้าอยากจะได้โปรแกรมแบบไหน ระบบอย่างไร ต้องพยายามถามออกมาให้ได้แม้ว่าเค้าจะไม่รู้เรื่องด้านเทคนิคเลยก็ตาม จากนั้นเราก็จะนำ Requirements ที่ได้มาวิเคราะห์เพื่อออกแบบระบบ โดยส่วนนี้จะต้องทำการแปลง Requirements ที่เป็นความต้องการของลูกค้าซึ่งไม่เกี่ยวข้องกับด้านเทคนิคใดๆ (ถ้าโชคดีเจอลูกค้าที่รู้เรื่องเทคนิคหน่อยก็คุยง่าย แต่ถ้าโชคร้ายเค้าไม่รู้เรื่องเราก็ต้องสามารถตีความต้องการของลูกค้าให้ได้) มาเป็นข้อมูลที่เป็นเชิงเทคนิค เพื่อนำมาใช้ในการออกแบบในขั้นตอนของการ Design ต่อไป
Design คือการนำ Requirements ที่ผ่านการวิเคราะห์แล้วมาออกแบบโครงสร้างของระบบทั้งหมดเช่น จะใช้วิธีการไหนในการพัฒนา, จะใช้เทคโนโลยีอะไร, จะใช้ Hardware แบบไหน โดยการออกแบบก็ต้องคำนึงถึงสิ่งต่างๆ มากมายทั้งจำนวนคนเข้าใช้, ความปลอดภัยของระบบ, ราคา (เทคโนโลยีต่างกันราคาก็ต่างกัน), และเรื่องอื่นๆ อีกมากมาย
Implementation คือการ Coding หรือช่วงการพัฒนา โดยในส่วนของ Design และ Implementation จะมีความเกี่ยวข้องกันค่อนข้างมาเพราะหาก Design ผิดพลาดก็จะทำให้ Implement ผิดพลาดเช่นกัน โดยเท่าที่ได้ยินมาเค้าจะใช้หลักการ 80-20 คือใช้เวลาในการออกแบบ 80% และเวลาในการเขียน Code 20% เพราะหากเราออกแบบได้ถูกต้อง เราก็ไม่ต้องกลัวว่าจะเขียน Code ได้ผิด ไม่ต้องมาไล่แก้ Code นั้นเอง
Verification คือส่วนของการทดสอบระบบที่เราพัฒนาขึ้นมา โดยจะเป็นการหาความผิดพลาดของระบบที่อาจจะเกิดขึ้น หรือเกิดขึ้นแล้ว แล้วก็ทำการแก้ไขเพื่อทำให้ระบบที่พัฒนาเกิดข้อพิดพลาดน้อยที่สุด
Maintenance คือส่วนของการส่งมอบ ติดตั้ง และดูแลระบบหลังจากพัฒนาเสร็จเรียบร้อย

ที่กล่าวมาข้างต้นเป็นหลักการคร่าวๆ ของ Waterfall Model ซึ่งเป็น SDLC หลักการของ Software Engineering ครับ โดยจากทั้งหมดที่กล่าวมายังไม่ได้พูดถึงเรื่อง Quality เพิ่มเติมอีกนะครับ ไม่ว่าจะเป็นเรื่องของ CMMI มาตรฐานในการพัฒนา หรือการทำ Software Configuration Management เพื่อควบคุม Version และปัญหาในการพัฒนา และยังมีเรื่องอื่นๆ ที่ต้องศึกษาอีก

และสุดท้ายโดยส่วนตัวแล้วไม่ทราบเหมือนกันว่าถ้าเป็น Software Engineer มันทำอะไร แต่เท่าที่ได้ยินมาเหมือนจะเป็นแค่ Developer หรือ Programmer เท่านั้นเองเพียงแค่เปลี่ยนชื่อเรียกใหม่เฉยๆ และโดยศาสตร์ของ Software Engineering เป็นเพียงแค่ศาสตร์ๆ หนึ่ง ซึ่งผมคิดว่า Software Engineer เพียงตำแหน่งเดียวคงไม่สามารถทำทั้งหมดที่กล่าวมาได้แน่นอน ดังนั้นจึงมีการแตกแยกไปไหนมากมายหลายอาชีพ ทั้ง Project Manager, Business Analyst, System Analyst, System Architect, Developer, Tester, Quality Assurance, Software Configuration Management Engineer, etc. โดยสายอาชีพที่กล่าวมานี้จะมีความเกี่ยวข้องกับศาสตร์ของ Software Engineering ครับ

ข้อมูลจากความรู้ที่ได้เรียน ได้ศึกษา และได้ฟังมาจากผู้มีประสบการณ์ในการทำงานเกี่ยวกับ Software Engineering ครับ

ผมว่า Waterfall model

mibtrex Mon, 14/02/2011 - 10:37

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

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

แต่การออกแบบ software นอกจากรูปร่างหน้าตาที่จะต้องออกแบบให้ดูแล้ว ยังต้องมีการออกแบบการใช้งานด้วย ถ้าลูกค้าต้องการ software ที่สามารถส่ง email ได้ เหล่าวิศวกรยังต้องมานั่งเลือกว่าจะใช้เทคโนโลยี pop3/smtp, exchange server, imap ซึ่งแต่ละอย่างก็มีข้อดีข้อเสียต่างกันไป ถ้าเลือกมาไม่ตรงใจลูกค้า ก็อาจจะต้องทำใหม่ได้

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

+1 แล้วก็ที่ผมยก Waterfall

piscessera Mon, 14/02/2011 - 23:10

+1
แล้วก็ที่ผมยก Waterfall เพราะใช้กันเยอะและเข้าใจได้ง่าย ไม่ซับซ้อนมากโดยส่วนใหญ่จะใช้เยอะกับหน่วยของภาครัฐเนื่องจากมันต้องเป็นไปตามกระบวนการเป็นขั้นเป็นตอน (จะทำ Process แต่ล่ะอย่างนานมาก อย่างจะหาข้อสรุปของ Requirement ทีก็ต้องดูแล้วดูอีกกว่าจะได้ก็เป็นหลายเดือน) แล้วก็แต่ล่ะ Model ก็มีข้อดีข้อเสียต่างกันไป ก็ต้องเลือกใช้ให้เหมาะสม แล้วก็ถ้าอยากให้ได้ตรงใจลูกค้าก็ต้องใช้ Agile แต่ก็มีข้อเสียที่ไม่ค่อยจะมี Document มา Support สักเท่าไร หรือจะใช้แบบ RUP ก็ได้แต่ก็ต้องการคนที่มีความสามารถนิดนึ่ง

+1 ต้องยอมรับเลยว่าเรื่องของ

kotokyo Tue, 15/02/2011 - 00:02

+1 ต้องยอมรับเลยว่าเรื่องของ Change และการพัฒนาซอฟต์แวร์เป็นของคู่กัน Software Engineering เองก็เกิดขึ้นมาเพื่อบริหารจัดการในส่วนนี้ด้วยเหมือนกัน เพื่อเป็นการอธิบายเพิ่มเติมให้คุณ By_Myself ที่ได้ตั้งกระทู้นี้ขึ้นมา ผมขอเสริมในเรื่องของการจัดการ Change อีกสักนิดละกันครับ

ถ้าหากเรามาลองคิดดูดีดีส่วนย่อยๆ ต่างๆ ของ Software Engineering นั้นก็ส่วนเกี่ยวข้องกับ Change ด้วยทั้งนั้น ผมขอเริ่มที่

Requirement Management ก็เพราะลูกค้ามักไม่เข้าใจสิ่งที่ตัวเองต้องการจริงๆ แต่แรก แต่จะค่อยๆ นึกออกมาทีละนิดๆ เปลี่ยนแปลงไปตามสิ่งที่เราเสนอไปให้ดู Requirement Management จึงเป็นเรื่องสำคัญมาก ที่จะทำให้ความต้องการนั้นอยู่ภายใต้ขอบเขตที่กำหนด และยอมรับได้ทั้งสองฝ่าย (ไม่งั้นก็เปลี่ยนไปเรื่อยๆ โปรเจคปิดไม่ลงซักที)
ถัดมาลองมาดูในส่วนของการทำ Software Configuration Management ที่เปรียบเสมือนการกำหนด, ควบคุม และบันทึก Change ที่เกิดขึ้น ไม่ว่าจะเป็นการควบคุม version ของ source code, tools, documents และยังเป็นการสำรองข้อมูลที่สำคัญๆ ของโปรเจคไปในตัวอีกด้วย
อีกเรื่องหนึ่งที่สำคัญไม่แพ้กันก็คือเรื่องของ Risk Management ซึ่งก็คล้ายๆ กับป้อมปราการที่เราจะเอาไว้รับมือกับ Change ที่มีความอันตรายต่อโปรเจค โดยจะแบ่งเป็นระดับๆ ตามความรุนแรงที่ประเมินได้เทียบกับความเสียหายที่อาจเกิดขึ้นกับโปรเจค (ดูจาก 3 ปัจจัยหลักๆ ได้แก่ เวลา เงิน และขอบเขตการพัฒนา)เพื่อที่ว่าเวลาที่มันเกิดขึ้นแล้ว เราจะสามารถรับมือ และจัดการกับมันได้อย่างทันท่วงที ด้วยวิธีการที่ผ่านการไตร่ตรองมาอย่างดีแล้วนั่นเอง

โดยส่วนตัวแล้วผมเชื่อว่า Software Engineering นั้นจะเน้นที่ ส่วนหลักๆ ก็คือ Change Management เพื่อรับมือกับความเปลี่ยนในทุกๆ ด้านที่อาจเกิดขึ้นระหว่างการพัฒนา และ Development process เพื่อให้การพัฒนาเป็นไปตามกระบวนการที่ดีที่สุด (process ที่ดีจะต้องสร้างจากการนำ best practice ในแต่ละจุดมาผสานเข้าด้วยกัน) การควบคุมคุณภาพของ Software ก็จะทำได้ง่ายขึ้น ส่งผลให้การพัฒนา Software มีมาตราฐานที่ดีมากยิ่งขึ้น ปัญหาจากการใช้งานลดน้อยลง และสามารถพัฒนาได้แล้วเสร็จไวกว่าเดิม

การทดสอบกล่องขาว กล่องดำ,

adente Mon, 14/02/2011 - 09:28

การทดสอบกล่องขาว กล่องดำ, เฟสการพัฒนา, ไดอะแกรมแบบต่างๆ มากมาย
ลองดูพวก Software Reverse Engineering ไปเลยสนุกกว่า