เอกสารประกอบการสอนรายวิชา 5003107 … · 2 2....

1

แผนบริหารการสอนประจําบทท่ี 1

เนื้อหาประจําบท

1. ซอฟตแวร

2. วิศวกรรมซอฟตแวร

3. ลักษณะของซอฟตแวร

4. ประเภทของซอฟตแวรแบงตามลักษณะการใชงาน

5. การพัฒนาวิศวกรรมซอฟตแวรใหมีความคงทนถาวร

6. ประโยชนของวิศวกรรมซอฟตแวร

7. ตัวอยางซอฟตแวรท่ีนาสนใจ

วัตถุประสงคเชิงพฤติกรรม

1. นักศึกษาสามารถอธิบายความหมายของซอฟตแวร วิศวกรรมซอฟตแวร ลักษณะของ

ซอฟตแวร ประเภทของซอฟตแบงแวรตามลักษณะการใชงานได

2. นักศึกษาสามารถอธิบายวิธีการพัฒนาวิศวกรรมซอฟตแวรใหมีความคงทนถาวรได

3. นักศึกษาสามารถอธิบายประโยชนของวิศวกรรมซอฟตแวร และยกตัวอยางซอฟตแวรท่ี

นาสนใจได

วิธีการสอนและกิจกรรมการเรียนการสอนประจําบท

1. วิธีการสอน

1.1 วิธีการสอนแบบบรรยาย เริ่มจากการอธิบายถึงความหมายของซอฟตแวร

วิศวกรรมซอฟตแวร ลักษณะของซอฟตแวร ประเภทของซอฟตแวรแบงตามลักษณะการใชงาน การ

พัฒนาวิศวกรรมซอฟตแวรใหมีความคงทนถาวร ประโยชนของวิศวกรรมซอฟตแวรพรอมท้ังยกตัวอยาง

ซอฟตแวรท่ีนาสนใจ

1.2 มีการตั้งคําถาม ตอบคําถามในชั้นเรียนระหวางผูสอนและผูเรียน

1.3 มีการอภิปราย สรุปประเด็นท่ีสําคัญของเนื้อหาในบทเรียนท่ี 1

2

2. กิจกรรมการเรียนการสอน

2.1 แสดงตัวอยางซอฟตแวรท่ีนาสนใจ

2.2 แบงกลุมอภิปรายเรื่องซอฟตแวรในปจจุบัน จุดเดน จุดดอยของซอฟตแวร

แตละประเภท

2.3 ทําแบบฝกหัดทายบทเรียนท่ี 1

สื่อการเรียนการสอน

1. เครื่องคอมพิวเตอร

2. โปรแกรมนําเสนอผลงาน และเว็บไซต amaritasite.wordpress.com/blog

3. เอกสารประกอบการสอนรายวิชาวิศวกรรมซอฟตแวร

การวัดและการประเมินผล

1. สังเกตการตอบคําถาม การรับรูเขาใจท่ีตรงกัน

2. สังเกตการคิดวิเคราะห สรุปความเปนไปตามแตละบทเรียนสอดคลองกับเนื้อหา

3. วัดเจตคติจากการสังเกตพฤติกรรมความกระตือรือรนในการทํากิจกรรมและคุณภาพของ

งาน

3

บทท่ี 1

บทนํา

ในบทนี้จะกลาวถึงความหมายของซอฟตแวร วิศวกรรมซอฟตแวร วิวัฒนาการของวิศวกรรม

ซอฟตแวรท่ีมีการพัฒนามาอยางตอเนื่องตั้งแตอดีตจนถึงปจจุบัน มีการนําเอาหลักการทางวิศวกรรมมา

ควบคุมกระบวนการในการพัฒนาซอฟตแวรใหมีคุณภาพท่ีสูงข้ึน ลักษณะท่ีสําคัญของซอฟตแวรอธิบาย

ถึงลักษณะของซอฟตแวรท่ีดีมีคุณภาพ โดยนักวิศวกรซอฟตแวรจะตองคํานึงถึงในการพัฒนาซอฟตแวร

นอกจากนี้การจําแนกประเภทของซอฟตแวรท่ีใชงานดานตางๆ การเลือกผลิตซอฟตแวรใหตรงกับความ

ตองการและงานดานตางๆ อยางเหมาะสม รวมถึงอธิบายถึงหลักการพัฒนาวิศวกรรมซอฟตแวรใหมี

ความคงทนถาวร ประโยชนของวิศวกรรมซอฟตแวรและตัวอยางของซอฟตแวรท่ีนาสนใจ

ซอฟตแวร

นิยามของซอฟตแวร โดย จอหน ดับเบิลยู. เทอรกีย (John W. Turkey) [Roger S. Pressman.

(2005)] กลาววา “ซอฟตแวรเปน ชุดคําสั่ง โปรแกรมคอมพิวเตอร ซ่ึงอาจถูกเรียกใชจากชุดคําสั่งและสั่ง

ใหคอมพิวเตอรทํางานได” นอกจากนี้ ซอฟตแวรยังรวมไปถึงเรื่องของการจัดการขอมูลสารสนเทศ การสั่ง

การควบคุมอุปกรณท่ีสําคัญ รวมไปจนถึงอุปกรณพกพา

ในราวทศวรรษ 1950 เปนท่ีรูจักกับคําวา เศรษฐกิจยุคใหม (The New Economy) ธุรกิจ

ดอทคอมซ่ึงควบคุมตลาดการเงินและในชวงทศวรรษ 2000 ทําใหผูคนสวนใหญเชื่อวาเศรษฐกิจยุคใหมได

หมดไป แตอันท่ีจริงเปนเพียงแคการเริ่มตนของยุคใหมเทานั้น และจะคอยๆ เขาสูการวิวัฒนาการอยาง

ชาๆ และแทรกเขาสูชีวิตประจําวัน ในงานทางดานวิทยาศาสตรและวิศวกรรมศาสตร อีกท้ังซอฟตแวรยัง

นําไปสูการพัฒนาดานอ่ืนๆ ท่ีสําคัญ เชน ซอฟตแวรดานพันธุวิศวกรรม (Genetic Engineering) ท่ี

นํามาใชดานเทคโนโลยีท่ีการสื่อสาร เชน โทรคมนาคม (Telecommunication) นอกจากนี้ซอฟตแวรยัง

ถูกนํามาใชงานในรูปแบบเชิงธุรกิจ อุตสาหกรรม เชน อุตสาหกรรมการพิมพ ซอฟตแวรเปนจุดเปลี่ยนทํา

ใหเกิดการปรับปรุงครั้งใหญของคอมพิวเตอร จากท่ีมีคอมพิวเตอรขนาดใหญนําไปสูยุคของคอมพิวเตอร

ขนาดเล็กลงเรียกวา คอมพิวเตอรสวนบุคคล (Personal Computer) การเชื่อมตอกันของคอมพิวเตอรท่ี

เปนท่ีรูจักกันดีในปจจุบันเรียกวา อินเทอรเน็ต (Internet) ระบบเครือขายขนาดใหญท่ีมีซอฟตแวรเปน

เครื่องมือในการทํางาน ซ่ึงถือกําเนิดข้ึนมาเพ่ือนําไปสูการเปลี่ยนแปลงครั้งใหญและครั้งสําคัญของหลาย

4

ภาคสวน และตอมาไมนานซอฟตแวรไดกลายเปนสิ่งท่ีฝงอยูในทุกระบบ เชน การคมนาคมขนสง

การทหาร อุตสาหกรรม ความบันเทิง อุปกรณสํานักงานและอ่ืนๆ อีกมากมาย

วิศวกรรมซอฟตแวร

นิยามของ วิศวกรรมซอฟตแวร คือการศึกษาในเรื่องของนําเอาหลักการทางวิศวกรรมมาควบคุม

กรรมวิธีในการพัฒนาซอฟตแวร ตลอดจนการบํารุงรักษาซอฟตแวรโดยมุงเนนวิธีการผลิตซอฟตแวรให

ประหยัดคาใชจายท่ีสุดและสามารถใชงานได นอกจากนี้ยังแบงนัยสําคัญของวิศวกรรมซอฟตแวรออกเปน

2 ประเด็น คือ

1. สหวิทยาการจัดการดานวิศวกรรม คือ การผสมผสานระหวางศาสตรและศิลปเพ่ือการผลิต

ซอฟตแวรโดยประยุกตใชศาสตรดานตางๆ ไมวาจะเปนทฤษฏีและปฏิบัติ ระเบียบวิธีและเครื่องมือตางๆ

ในการบริหารจัดการเก่ียวกับทรัพยากรไดอยางเหมาะสม

2. ผูเชี่ยวชาญดานการผลิตซอฟตแวร คือ วิศวกรซอฟตแวรท่ีมีความชํานาญในการผลิต

ซอฟตแวร โดยใชเทคนิคและกระบวนการไดอยางมีประสิทธิภาพ

ในมุมมองของนักคอมพิวเตอรนั้น นักคอมพิวเตอรจะใหความสําคัญกับการเลือกซอฟตแวรและ

นําซอฟตแวรท่ีผลิตข้ึนมาอยางมากมายนั้นไปใชให เกิดประโยชนสูงสุด แตกตางกับมุมมองของ

นักวิศวกรซอฟตแวรจะคิดคนกรรมวิธีข้ันตอนในการพัฒนาซอฟตแวรใหมีประสิทธิภาพมากท่ีสุด

วิวัฒนาการของวิศวกรรมซอฟตแวร

วิวัฒนาการของวิศวกรรมซอฟตแวรไดมีพัฒนาการมาอยางตอเนื่อง โดยสามารถแบง

ออกเปน 3 ชวงเวลา ดั้งนี ้

1. ชวงเริ่มตนของวิศวกรรมซอฟตแวร ระหวางป ค.ศ. 1945 – 1965 ในชวงแรกนี้มีกลาวถึง

วิศวกรรมซอฟตแวร จะเปนท่ีรูจักกันเพียงเฉพาะกลุมของผูพัฒนาซอฟตแวรเทานั้น กลุมบุคลากรเหลานี้

มุงเนนผลิตซอฟตแวรเพ่ือการคา จนกระท้ังองคกรนาโต (NATO) ไดมีการจัดสัมนาวิศวกรรมซอฟตแวรข้ึน

ครั้งแรกเม่ือป ค.ศ. 1968 ณ ประเทศเยอรมัน จึงเปนการจุดประกายใหศาสตรทางดานวิศวกรรม

ซอฟตแวรและซอฟตแวรคอมพิวเตอรเปนท่ีรูจักมากยิ่งข้ึน

2. ชวงกลางของวิศวกรรมซอฟตแวร ระหวางป ค.ศ. 1965 – 1985 เนื่องจากชวงกอนหนา

มุงเนนการผลิตซอฟตแวรเปนจํานวนมาก โดยไมไดคํานึงถึงตนทุนการผลิต งบประมาณท่ีใช หรือ

แมกระท่ังขอจํากัดเรื่องของเวลาในการพัฒนาซอฟตแวร โดยในชวงเวลาท่ียากลําบากนี้ทําใหเกิด

วิกฤตการณจึงเปนเหตุใหตองจางนักวิศวกรซอฟตแวรท่ีมีความรูความสามารถระดับมืออาชีพท่ีสามารถ

5

ผลิตซอฟตแวรท่ีมีคุณภาพสูง ซอฟตแวรท่ีถูกผลิตข้ึนมาในชวงกลางนี้เชน ซอฟตแวรระบบปฏิบัติการ

OS/360 ซ่ึงเปนซอฟตแวรท่ีมีระยะเวลาในการผลิตท่ีนานถึง 10 ป มีมูลคาการลงทุนท่ีสูงและมีจํานวน

นักพัฒนาซอฟตแวรจํานวนมากแตเม่ือผลิตเสร็จสิ้นแลวกลับใชงานซอฟตแวรไดไมดีเทาท่ีควรจะเปน

3. ชวงป ค.ศ.1985 – ปจจุบัน การพัฒนาทางดานซอตแวรยังคงดําเนินมาอยางตอเนื่อง โดยมี

งานวิจัยเปนเครื่องมือผลักดันใหการผลิตซอฟตแวรนั้นเติบโตข้ึน การนําเทคโนโลยีสมัยใหมเขามาชวยใน

การผลิต รวมถึงวิธีการพัฒนาซอฟตแวรรูปแบบใหม อาจจะกลาวไดวาเปนยุคของการแกปญหาวิกฤต

ซอฟตแวรอยางแทจริง ปจจัยท่ีเปนแรงขับเคลื่อนของการพัฒนาซอฟตแวรมีดังตอไปนี้

เครื่องมือ มีการคิดคนเครื่องมือและพัฒนาเครื่องมือเพ่ืออํานวยความสะดวกในการพัฒนา

ซอฟตแวร เชน เคสทูล (Case Tool) ยูเอ็มแอล (UML) รวมถึงมาตรฐานตางๆ ท่ีกําหนดคุณภาพของ


กระบวนการ มีการกําหนดระเบียบวิธีในการพัฒนาซอฟตแวรใหมีคุณภาพ รวมถึงกระบวนการ

ในการปรับปรุงคุณภาพซอฟตแวร

ลักษณะของซอฟตแวร

ซอฟตแวรนั้นเปรียบไดกับผลิตภัณฑ ดังนั้นการพัฒนาซอฟตแวรจึงจําเปนจะตองทําความเขาใจ

เก่ียวกับลักษณะซอฟตแวรท่ีดีมีคุณภาพ สามารถอธิบายไดดังนี้

1. ซอฟตแวรเปนสิ่งท่ีมองไมเห็นและจับตองไมได ท้ังนี้การพัฒนาซอฟตแวรข้ึนอยูกับหลาย

ปจจัย ดังนั้นเม่ือถึงเวลาท่ีจะตองทําการทดสอบประสิทธิภาพจึงเปนไปไดลําบาก

2. ซอฟตแวรสามารถนํากลับมาใชไดใหม หลายครั้งพบวาการนํากลับมาใชใหมของซอฟตแวร

นั้นมีสวนชวยใหนักพัฒนาทํางานไดสะดวกข้ึน

3. ในมุมมองของอุตสาหกรรมการผลิตซอฟตแวรนั้น อาจจะไมไชเครื่องจักรในการผลิต หากแต

เปนการจัดตั้งทีมทํางานท่ีมีความรูความสามารถ เพ่ือพัฒนาซอฟตแวรใหไดประสิทธิภาพมากท่ีสุด

4. ซอฟตแวรท่ีดีตองไมเปลี่ยนไปตามกาลเวลา หากจะตองคงอยูและใชงานไดอยางคงทน

5. ซอฟตแวรถูกพัฒนาหรือจัดการใหเกิดข้ึน หากเปรียบเทียบการผลิตซอฟตแวรกับการผลิต

โรงงานอุตสาหกรรมท่ัวไปแลวนั้น อาจจะมีความคลายกันอยูบางในเรื่องการไดมาซ่ึงผลิตภัณฑ โดยท่ี

มุงหวังใหมีคุณภาพตามท่ีลูกคากําหนด

6. ซอฟตแวรท่ีไมสึกหรอ ในมุมมองของนักพัฒนาซอฟตแวรนั้น มักพบความลมเหลวอยูบางใน

ข้ันตอนของการพัฒนาชวงแรกๆ เนื่องจากการเริ่มตนท่ีอาจจะยังไมเขาใจกันอยูบางแตเม่ือเวลาผานไป

พบวาอัตราความลมเหลวนั้นลดลง และซอฟแวรท่ีพัฒนาก็จะกลายเปนซอฟตแวรท่ีคงทนถาวร

6

7. แมวาอุตสาหกรรมซอฟตแวรกําลังมุงไปสูการสรางจากองคประกอบยอย ถึงแมวาการพัฒนา

ซอฟตแวรสําเร็จรูปจะเปนท่ีแพรหลายเปนอยางมาก หากแตความตองการของลูกคาท่ีมีความตองการ

ซอฟตแวรเฉพาะงานนั้นก็ยังคงมีอยูมากเชนกัน

ประเภทของซอฟตแวรแบงตามลักษณะการใชงาน

ในปจจุบันสามารถแบงประเภทของซอฟตแวรออกเปน 10 แบบตามลักษณะการใชงาน ดังนี้

1. ซอฟตแวรระบบซอฟตแวรระบบ เปนชุดโปรแกรมท่ีเขียนข้ึนเพ่ือใหบริการติดตอ ควบคุม

การทํางานพ้ืนฐานของฮารดแวร อีกท้ังการแปลความหมายของคอมพิวเตอรเพ่ือไปแสดงผล

2. ซอฟตแวรประยุกตซอฟตแวรประยุกต ท่ีพัฒนาข้ึนมาเพ่ือวัตถุประสงคการใชงานเฉพาะ

อยาง เชน การประมวล ณ จุดขาย การควบคุมกระบวนการผลิตตามเวลาจริง

3. ซอฟตแวรเชิงวิศวกรรม/วิทยาศาสตร ซอฟตแวรในกลุมนี้มักเปนข้ันตอนวิธีท่ีชวยในการ

คํานวณ มีการใชงานกวางตั้งแตทางดานดาราศาสตร ชีววิทยา ฟสิกส เคมีและอ่ืนๆ ในงานบางลักษณะจะ

มีการจําลองวิธีการทํางานการคํานวณในเชิงวิศวกรรม เพ่ือใหเห็นผลการทํางานเหลานั้นเพ่ือประกอบการ

ตัดสินใจ

4. ซอฟตแวรฝงตัว เปนซอฟตแวรท่ีฝงอยูในตัวผลิตภัณฑ อุปกรณหรือตัวระบบท่ีมีไวเพ่ือให

สามารถใชและควบคุมลักษณะและหนาท่ีตางๆ ปจจุบันเราพบอยูในอุปกรณไฟฟา เครื่องครัว หรือ

แมกระท่ังอุปกรณในชีวิตประจําวัน เชน นาฬิกา

5. ซอฟตแวรสายการผลิตเปนซอฟตแวรท่ีมีความสามารถเฉพาะดานการผลิต เพ่ือใหใชไดกับ

ลูกคาท่ีแตกตางกันซอฟตแวรประเภทนี้เนนเฉพาะกลุมบุคคล

6. เว็บแอพพลิเคชัน เปนซอฟตแวรท่ีใชงานงาย มีความสามารถในการใชงานสูง เรามักจะใช

เว็บแอพพลิเคชันในการแสดงผลขอความเชื่อมโยงและกราฟฟกตางๆ

7. ซอฟตแวรปญญาประดิษฐเพ่ือแกปญหาท่ีมีความซับซอนกวาการวิเคราะหคํานวณแบบ

ตรงๆ เชน วิทยาการหุนยนต (Robotics) ระบบผูเชี่ยวชาญ (Expert System) การเรียนรูจําแบบ

(Pattern Recognition) โครงข ายประสาท เทียม (Artificial Neural Network) การพิสู จน ทฤษฎี

(Theorem Proving) และการเลนเกม (Game Playing)

8. การประมวลผลไดทุกท่ี จากการพัฒนาไปอยางรวดเร็วของเครือขายไรสาย ( W i r e l e s s

Network) นํามาสูการประมวลผลคอมพิวเตอรแบบกระจาย (Distributed Computing) ท่ีสามารถ

ทํางานไดอยางรวดเร็ว

9. อินเทอรเน็ต การพัฒนาซอฟตแวรเพ่ือตอบสนองโลกของเวิลดไวดเว็บเปนตัวขับเคลื่อน

สําคัญสําหรับงานคอมพิวเตอร นักวิศวกรซอฟตแวรจะตองสรางแอพพลิเคชันท่ีงายและทันสมัย และทําให

ผูใชท่ัวโลกใชประโยชนไดเทาเทียมกัน

7

10. โอเพนซอรส เปนคุณสมบัติท่ีเดนชัดของซอฟตแวรกลุมนี้เนื่องจากเปนวิธีการพัฒนซอฟตแวร

โดยการเปดเผยรูปแบบวิธีการพัฒนา รูปแบบการเขียนโคดโปรแกรมเพ่ือใหผูท่ีมีความสนใจมาพัฒนา

รวมกันไดตอไป

ความทาทายสําหรับนักวิศวกรซอฟตแวร คือ จะตองหาวิธีท่ีจะสรางแอพพลิเคชันท่ีจะอํานวย

ความสะดวกในการติดตอสื่อสาร เพ่ือใหการใชซอฟตแวรท่ีพัฒนาข้ึนนั้นไดแพรกระจายไปอยางรวดเร็ว

การพัฒนาวิศวกรรมซอฟตแวรใหมีความคงทนถาวร

ลักษณะของซอฟตแวรคอมพิวเตอรท้ัง 10 แบบท่ีไดกลาวมาในหัวขอท่ีแลวนั้น บางโปรแกรมถูก

สรางข้ึนดวยเทคนิคอันทันสมัยท่ีเพ่ิงเกิดข้ึน บางโปรแกรมท่ีเกาแลว และบางโปรแกรมก็เกามากข้ึนไปอีก

โปรแกรมท่ีเกาแกเหลานี้ อาจเรียกไดวา “ซอฟตแวรท่ีมีความคงทนถาวร” แสดงใหเห็นถึงคุณภาพของ

การพัฒนาซอฟตแวรท่ีสามารถใชงานไดดีเม่ือเวลาผานไป

ลักษณะซอฟตแวรท่ีไมมีความคงทน มีคุณภาพต่ํา มักจะมีการออกแบบท่ีขยายตอไมได การเขียน

โปรแกรมท่ียุงยาก ไมมีคูมือการใชหรือมีแตไมสามารถนํามาใชงานได แตอยาลืมวาซอฟตแวรท่ีมีคุณภาพ

นั้นสามารถสนับสนุนหนาท่ีหลักของธุรกิจ (Core Business Function) และเปนสิ่งท่ีธุรกิจขาดไมได สวน

ซอฟตแวรท่ีมีคุณภาพตองการการปรับเปลี่ยน โดยมีสาเหตุท่ีเปนไปไดตางๆ ดังนี้

1. ซอฟตแวรตองถูกปรับใหเขากับเทคโนโลยีท่ีเปลี่ยนไปหรือไม เชน ระบบจัดการฐานขอมูล

2. ซอฟตแวรตองไดรับการปรับเปลี่ยนเพ่ิมคุณสมบัติใหทันสมัยหรือไม เชน การปรับฟงกชัน

สําหรับการเชื่อมตอกับอุปกรณอ่ืนท่ีทันสมัย

3. ซอฟตแวรตองไดรับการปรับปรุงขอมูลขาวสารท่ีทันสมัยหรือไมเม่ือวิวัฒนาการตางๆ เหลานี้

คอยๆ เกิดข้ึน ทําใหระบบซอฟตแวรลายครามตองไดรับการปรับปรุงในทายท่ีสุด เปาหมายของวิศวกรรม

ซอฟตแวรสมัยใหมอยางหนึ่งก็คือ “เพ่ือคิดระเบียบวิธีซ่ึงพบไดในการวิวัฒนาการ” นั้นคือความคิดท่ีวา

“ซอฟตแวรเปลี่ยนแปลงอยูทุกขณะ” ระบบซอฟตแวรใหมๆ ไดรับการสรางข้ึนจากระบบเกาๆ และระบบ

ท้ังหมดตองสอดคลอง และทํางานรวมกันอยางมีประสิทธิภาพ

4. ซอฟตแวรตองงายกับการบํารุงรักษา เม่ือมีการใชงานซอฟตแวรไประยะหนึ่งนั้น อาจจะมี

ความจําเปนท่ีจะตองติดต้ังฟงกชันการใชงานท่ีจําเปนเพ่ิมเติม ดังนั้นการบํารุงรักษาจึงจําเปนท่ีตอง

คํานึงถึง เพ่ือใหสามารถใชซอฟตแวรนั้นไดอยางมีประสิทธิภาพเชนเดิม

5. ซอฟตแวรจะตองคงใวซ่ึงความนาเชื่อถือ คงเสนคงวา ไมวาจะเปนการทํางานของฟงกชัน

ท้ังหมด การตอบสอง รวมไปถึงการรักษาความปลอดภัยอันเกิดจากสถานการณท่ีไมคาดคิดได

8

6. ซอฟตแวรตองมีความสามารถในการใชงานไดตามวัตถุประสงค เปนสิ่งจําเปนท่ีซอฟตแวร

จะตองทํางานไดในสภาวะปกติ และมีสวนสํารองในสภาวะท่ีเกิดเหตุการณไมพึงประสงค

ประโยชนของวิศวกรรมซอฟตแวร

การนําเอาหลักการทางวิศวกรรมซอฟตแวรเขามาชวยในการกําหนดกระบวนการของการผลิต

ซอฟตแวรสงผลใหเกิดประโยชนหลายดาน ดังภาพท่ี 1.1

1. มีกระบวนการผลิตซอฟตแวรท่ีมีประสิทธิภาพ นักวิศวกรซอฟตแวรเลือกหลักของกระบวน

การผลิตซอฟตแวรใหเหมาะสมกับซอฟตแวรท่ีผลิต

2. มีการกําหนดมาตรฐานวิธีการทํางานอยางชัดเจน นักวิศวกรซอฟตแวร ไดกําหนดมาตรฐาน

ของการพัฒนาซอฟตแวร และดําเนินการควบคุมใหอยูในมาตรฐานท่ีกําหนด

3. มีการตรวจสอบคุณภาพของซอฟตแวร เปนหนาท่ีของทีมงานพัฒนาซอฟตแวรจะมีเครื่องมือ

ในการตรวจสอบความถูกตองและคุณภาพของซอฟตแวรใหเปนไปตามท่ีกําหนดใว

4. มีเอกสารควบคุมกํากับการทํางานตลอดท้ังกระบวนการ จัดทําเอกสารข้ันตอนกระบวนการ

ทํางาน คูมือการใชงาน ตลอดจนรวบรวมขอมูลของการพัฒนาซอฟตแวรทุกข้ันตอน

5. มีการตรวจสอบและประกันคุณภาพของซอฟตแวรท่ีผลิตกอนสงถึงมือผูบริโภค เพ่ือใหม่ันใจ

ถึงคุณภาพของซอฟตแวรท่ีผลิต

6. การกําหนดกระบวนการ กําหนดมาตรฐานทําใหสามารถทํางานได ถึงแมวาจะเปลี่ยนทีมงาน

ภาพท่ี 1.1 แสดงประโยชนของวิศวกรรมซอฟตแวร

ตัวอยางซอฟตแวรที่นาสนใจ

โปรแกรมดรอปบอก (Dropbox) เปนบริการเชื่อมโยง (Synchronize) และฝากไฟลขอมูลแบบ

ออนไลน ผูใชงานสามารถจัดเก็บและแบงปนแฟมขอมูลรวมกับผูอ่ืนได หรือคนในองคกรสามารถเขามา

ใชงานไฟลขอมูลรวมกันได โดยสามารถเขาถึงแฟมขอมูลตางๆ ไดจากการเชื่อมตออินเทอรเน็ต เม่ือ

ผูใชงานติดตั้งตัวโปรแกรมแลว ซอฟตแวรดรอปบอกจะสรางแฟมชั่วคราวเพ่ือจัดเก็บข้ึนมาในเครื่อง

มีการกําหนดมาตรฐาน มีการตรวจสอบ

การกําหนดกระบวนการ มีการตรวจสอบและประกันคุณภาพ มีเอกสารควบคุมกํากับ

วิศวกรรมซอฟตแวร

มีกระบวนการผลิตซอฟตแวร

9

เปรียบเสมือนการจําลองไดรฟเก็บขอมูล การติดตั้งและใชงานโปรแกรมดรอปบอกนั้นสามารถติดตั้งได

หลายระบบปฏิบัติการ เชน Windows, Mac, Linux, iPhone, iPad และ BlackBerry จุดเดนของ

โปรแกรมสามารถทําการเชื่อมโยงขอมูล โปรแกรมดรอปบอกจะทําไฟลในแฟมขอมูลใหเชื่อมโยงกันได

โดยมีพ้ืนท่ีในการจัดเก็บขนาดใหญถึง 2GB แตยังพบจุดดอยบางประการเก่ียวกับโปรแกรมดรอปบอก คือ

มีการเก็บขอมูลท่ีมากจนเกินไปทําใหยากตอการคนหาหรือมีความลาชาในการโหลดขอมูล และมีขอจํากัด

เก่ียวกับการใชงานท่ีจําเปนตองใชการเชื่อมตออินเทอรเน็ตในการใชงาน

บทสรุป

ปจจุบันซอฟตแวรไดมีบทบาทสําคัญตอการใชชีวิตประจําวัน การพัฒนาซอฟตแวรไดเปลี่ยน

แปลงเปนการพัฒนาแบบอุตสาหกรรม ดังนั้นจึงมีการหาจุดคุมทุนของการพัฒนาซอฟตแวร

กระบวนการทางดานวิศวกรรมไดเขามาชวยในการควบคุมกระบวนการตางๆ ในการพัฒนาใหซอฟตแวรมี

คุณภาพมากยิ่งข้ึน เรียนรูถึงลักษณะของซอฟตแวร และประเภทของซอฟตแวรแบงตามลักษณะการใช

งาน เพ่ือสามารถนํามาใชในชีวิตประจําวันได ซอฟตแวรยังกลายเปนเครื่องมือชวยในการวิเคราะหขอมูล

และเขาถึงการใชงานไดงายข้ึน ดังนั้นจึงมีการเรียนรูการพัฒนาวิศวกรรมซอฟตแวรใหมีความคงทนถาวร

การเรียนรูการพัฒนาวิศวกรรมซอฟตแวรทําใหเกิดประโยชนในการผลิตซอฟตแวรท่ีไดรับประสิทธิภาพ

เชน โปรแกรมดรอปบอก ท่ีชวยในการแบงปนไฟลขอมูลขนาดใหญบนเครือขายอินเตอรเน็ต

10

คําถามทายบท

1. จงอธิบายความหมายของซอฟตแวรและวิศวกรรมซอฟตแวร

2. จงอธิบายความสําคัญของวิศกรรมซอฟตแวร

3. จงอธิบายชนิดของซอฟตแวรตามลักษณะการใชงาน บทบาทและหนาท่ีของซอฟตแวร

4. จงอธิบายลักษณะของซอฟตแวร

5. จงอธิบายประโยชนของวิศวกรรมซอฟตแวร

6. จงอธิบายพรอมยกตัวอยางซอฟตแวรทางดานอุตสาหกรรม 1 ตัวอยาง

7. จงอธิบายพรอมยกตัวอยางซอฟตแวรท่ีใชในการคํานวณทางวศิวกรรม 1 ตัวอยาง

8. จงอธบิายเก่ียวกับวิกฤตของการพัฒนาซอฟตแวร เพราะเหตุใดจึงทําใหซอฟตแวรไมมีคุณภาพ

9. จงอธิบายประโยชนของซอฟตแวรท่ีฝงตัวในอุปกรณไฟฟาใชในชีวิตประจําวัน

10. จงอธิบายแนวโนมของการพัฒนาซอฟตแวรในอนาคต

11

อางอิง

กิตติ ภักดีวัฒนะกุล และพนิดา พานิชกุล. (2550). วิศวกรรมซอฟตแวร. (พิมพครั้งท่ี 1). กรุงเทพฯ:

บ.ซีเอ็ดยูเคชัน จํากัด (มหาชน).

น้ําฝน อัศวเมฆิน. (2558). หลักพ้ืนฐานของวิศกวรรมซอฟตแวร . (พิมพครั้งท่ี 2). กรุงเทพฯ :


วิทยา สุคตบวร. (2008). วิศวกรรมซอฟตแวรเบ้ืองตน. (พิมพครั้งท่ี 1). กรุงเทพฯ: บ.ซีเอ็ดยูเคชัน จํากัด

(มหาชน).

สมชาย กิตติชัยกุลกิจ. (2548). เรื่องซอฟตแวรมีแคนี้. กรุงเทพฯ: สมาคมสงเสริมเทคโนโลยีไทย (ไทย-

ญี่ปุน).

Roger S. Pressman.(2005). Software Engineering. (6th ed.). Mc-Graw-Hill.

IEEE Software, March/April 2002. (IEEE Software, 19 (2), 2002.) [online]

http://www2.computer.org/portal/web/software.

13


หัวขอเนื้อหาประจําบทเรียน

1. กระบวนการผลิตซอฟตแวรเทคโนโลยีแบบชั้น

2. วงจรการพัฒนาระบบ

3. กลุมกิจกรรมท่ีสงเสริมเก่ียวกับการพัฒนาซอฟตแวรใหมีคุณภาพ

4. การปรับปรุงกระบวนการดวยซีเอ็มเอ็มไอ

5. วิธีการประเมินตามมาตรฐาน

6. รูปแบบของกระบวนการ

7. กระบวนการของซอฟตแวรสวนบุคคล

8. เครื่องมือและวิธีท่ีใชในกระบวนการพัฒนาซอฟตแวร


1. นักศึกษาสามารถอธิบายความหมายของกระบวนการผลิตซอฟตแวรเทคโนโลยีแบบชั้น วงจร

การพัฒนาระบบ กลุมกิจกรรมท่ีสงเสริมเก่ียวกับการพัฒนาซอฟตแวรใหมีคุณภาพ การปรับปรุง

กระบวนการดวยซีเอ็มเอ็มไอ วิธีการประเมินตามมาตรฐาน รูปแบบของกระบวนการได

2. นักศึกษาสามารถอธิบายการประเมินกระบวนการซอฟตแวรใหไดคุณภาพ แบบจําลองวุฒิ

ภาวะและความสามารถเชิงบูรณาการได

3. นักศึกษาสามารถอธิบายกระบวนการของซอฟตแวรสวนบุคคล เครื่องมือและวิธีท่ีใชใน

กระบวนการพัฒนาซอฟตแวรได



1.1 วิธีการสอนแบบบรรยาย เริ่มจากการใหความหมายของกระบวนการผลิตซอฟตแวร

เทคโนโลยีแบบชั้น วงจรการพัฒนาระบบ กลุมกิจกรรมท่ีสงเสริมเก่ียวกับการพัฒนาซอฟตแวรใหมีคุณภาพ

การปรับปรุงกระบวนการดวยซีเอ็มเอ็มไอ วิธีการประเมินตามมาตรฐาน รูปแบบของกระบวนการ

กระบวนการของซอฟตแวรสวนบุคคล เครื่องมือและวิธีท่ีใชในกระบวนการพัฒนาซอฟตแวร



14


2.1 แสดงตัวอยางการประเมินกระบวนการ

2.2 แบงกลุมอภิปรายเรื่องการปรับปรงุกระบวนการดวยซีเอ็มเอ็มไอ









3. วัดเจตคติจากการสังเกตพฤติกรรมความกระตือรือรนในการทํากิจกรรมและคุณภาพของงาน

15

บทท่ี 2

วิธีการพัฒนาซอฟตแวร

ในบทนี้จะกลาวถึงวิธีการพัฒนาและกระบวนการผลิตซอฟตแวรท่ีมีคุณภาพท่ีจําเปนจะตองอาศัย

เทคนิคสําหรับใชในกระบวนการพัฒนาซอฟตแวรเทคโนโลยีแบบชั้น เปนกลยุทธท่ีพัฒนาซอฟตแวรอยาง

เปนลําดับอยางมีข้ันตอน วงจรการพัฒนาระบบสงผลใหเกิดกิจกรรมท่ีเกิดข้ึนระหวางการผลิตซอฟตแวร

เปนสวนท่ีสําคัญมากเพราะทําใหไดมาซ่ึงซอฟตแวรท่ีมีคุณภาพ ซ่ึงไมตางกันกับการผลิตสินคาโดยท่ัวไป

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

และซอฟตแวรก็เชนกัน ในการผลิตซอฟตแวรใหมีคุณภาพนั้นตองอาศัยการปรับปรุงกระบวนการท่ีมี

ประสิทธิภาพดวย เชน การปรับปรุงกระบวนการดวยซีเอ็มเอ็มไอ วิธีการประเมินตามมาตรฐานไอโซ

นอกจากนี้ยังอธิบายรูปแบบของกระบวนการ และกระบวนการของซอฟตแวรสวนบุคคล เครื่องมือและวิธี

ท่ีใชในกระบวนการพัฒนาซอฟตแวร ดังจะอธิบายตอในสวนท่ีสําคัญดังตอไปนี้

กระบวนการผลิตซอฟตแวรเทคโนโลยีแบบช้ัน

ข้ันตอนการทํางานท่ีประกอบดวยกิจกรรมท่ีมีความสําคัญ มีขอจํากัดเง่ือนไขในการทํางานและ

ทรัพยากรท่ีใชในการผลิต โดยท่ัวไปแลวกระบวนการการผลิตนั้นจะตองระบุกิจกรรมท่ีชัดเจน ขอกําหนด

ในการใชทรัพยากรอาจจะหมายถึงระยะเวลา หรืองบประมาณท่ีมีอยูอยางจํากัด กิจกรรมตางๆ จะมีการ

กําหนดเริ่มตนและสิ้นสุด ท่ีสําคัญคือตองทําใหบรรลตุามวัตถุประสงค วิศวกรรมซอฟตแวรจึงถือเปน

กระบวนการพัฒนาผลิตภัณฑท่ีเกิดข้ึนแบบหนึ่ง โดยมุงหวังใหผูใชสามารถใชงานซอฟตแวรท่ีตรงตาม

วัตถุประสงค และมีคุณภาพ

การผลิตซอฟตแวรโดยใชเทคโนโนโลยีแบบชั้น เปนกลยุทธในการผลิตซอฟตแวรท่ีมีคุณภาพโดย

แบงออกเปนลําดับชั้น เชน เครื่องมือ วิธีการ กระบวนการ และการควบคุมคุณภาพ โดยแตละชั้นจะ

ทํางานประสานเชื่อมโยงกันทําใหไดซอฟตแวรท่ีมีคุณภาพมากท่ีสุด ดังภาพท่ี 2.1

ภาพท่ี 2.1 แสดงลําดับชั้นของวิศวกรรมซอฟตแวร

เครื่องมือ

วิธีการ

กระบวนการ

การควบคุมคุณภาพ

16

วงจรการพัฒนาระบบ

วงจรการพัฒนาระบบ SDLC (System Development Life Cycle) เปนข้ันตอนการทํางานใน

การผลิตซอฟตแวร จําเปนจะตองมีกรอบกิจกรรมของงาน Framework Activity มีหนาท่ีอธิบายจําลอง

การทํางานของกิจกรรมตางๆ ใหบรรลุตามวัตถุประสงค มีสวนท่ีสําคัญดังนี้

1. การสื่อสาร (Communication) เปนกิจกรรมพ้ืนฐานของกรอบงานเก่ียวของกับการพัฒนา

ซอฟตแวร การติดตอสื่อสารและการทํางานรวมกันกับลูกคา และผูมีสวนรวมในการพัฒนาระบบ กิจกรรม

นี้เปนกิจกรรมท่ีรวบรวมขอมูลดานความตองการ (Requirements Gathering) เขาไวดวยกัน เชน

การประชุมเพ่ือเริ่มงาน การแบงปนขอมูลเพ่ือการพัฒนาซอฟตแวรท่ีมีประสิทธิภาพ

2. การวางแผน (P l a n n i n g) เปนกิจกรรมท่ีสําคัญเพราะเปนสวนของการกําหนดแผนงาน

วางแผนการทํางานรวมถึงการใชทรัพยากรท่ีสําคัญ การวางแผนงานเชิงเทคนิคท่ีจะตองคํานึงถึงความเสี่ยง

ท่ีอาจเกิดข้ึนกอใหเกิดความเสียหายได รวมถึงผลงานท่ีตองการและตารางการทํางานเปนตน

3. การสรางแบบจําลอง (Mod e l i n g) เปนกิจกรรมท่ีทําการสรางแบบจําลองเพ่ือชวยในการ

สื่อสารระหวางผูพัฒนาซอฟตแวรและลูกคา สรางความเขาใจถึงความตองการทางซอฟตแวรไดดีข้ึน และ

เขาใจตรงกันถึงการออกแบบซ่ึงจะนําไปสูความสําเร็จของการพัฒนาซอฟตแวร

4. การสราง (Construction) เปนกิจกรรมการเขียนโปรแกรม ซ่ึงอาจจะใชเครื่องมือท่ีพัฒนา

ซอฟตแวรดวยภาษาหรือคอมไพเลอรท่ีเหมาะสม รวมถึงการทดสอบตรวจหาขอผิดพลาดของโปรแกรม

ในการใชงาน เปนกิจกรรมท่ีนําซอฟตแวรท่ีผลิตเสร็จแลว ตลอดจนถึงการสงมอบใหแกลูกคา โดยลูกคา

จะเปนผูประเมินและใหความคิดเห็นเก่ียวกับผลิตภัณฑ

กลุมกิจกรรมที่สงเสริมเกีย่วกับการพัฒนาซอฟตแวรใหมีคุณภาพ

กิจกรรมท่ีเกิดข้ึนนั้น สงเสริมใหมีการพัฒนาซอฟตแวรท่ีมีคุณภาพมากยิ่งข้ึน พบวาในหลาย

รูปแบบการพัฒนาซอฟตแวรมีการตรวจสอบหาขอผิดพลาดของทุกข้ันตอนในการพัฒนา เม่ือพบ

ขอบกพรองมีการปรับปรุงแกไขอยูตลอดสงผลใหซอฟตแวรท่ีผลิตมีคุณภาพมากยิ่งข้ึน นอกจากกิจกรรมท่ี

กลาวมาแลวยังมีกลุมกิจกรรมท่ีสงเสริมเก่ียวกับการพัฒนาซอฟตแวรใหมีคุณภาพ ดังนี้

1. การติดตามและควบคุมโครงการซอฟตแวร (Software Project Tracking and Control)

หมายถึงกลุมกิจกรรม ท่ีทําใหทีมงานพัฒนาซอฟตแวรไดรับทราบเก่ียวกับความกาวหนาของโครงการวา

เปนไปตามแผนท่ีวางไวหรือไม ทีมงานพัฒนาซอฟตแวรจะตองพิจารณากิจกรรมท่ีกอใหเกิดความลาชา

เพ่ือท่ีจะรักษาตารางเวลาเพ่ือใหตรงกับแผนงานการสงมอบงานท่ีไดกําหนดไว

17

2. การจัดการความเสี่ยง (Risk Management) หมายถึงผูประเมินความเสี่ยงมีหนาท่ีในการ

ตรวจสอบ พิจารณาถึงความเสี่ยงท่ีอาจจะเกิดข้ึนระหวางการดําเนินกิจกรรม ซ่ึงอาจสงผลตอผลลัพธของ

โครงการ หรือคุณภาพของผลิตภัณฑท่ีลดลง

3. การประกันคุณภาพซอฟตแวร (Software Quality Assurance) เปนกิจกรรมท่ีทีมงาน

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

4. การพิจารณาดานเทคนิค (Formal Techn ica l As su rance) เปนการประเมินเพ่ือ

หาและขจัดขอบกพรองทางดานเทคนิค กอนท่ีจะไปทํากิจกรรมถัดไป

5. การวัด (Measurement) เปนวิธีการวัดผลกระบวนการ โครงการและผลิตภัณฑ ซ่ึงชวย

ในการสงมอบซอฟตแวรท่ีเปนไปตามความตองการของลูกคา โดยวธิีการวัดอาจจะเปนไปไดหลายวิธี

ดวยกัน เชน วัดคุณภาพการใชงาน ความผิดพลาดท่ีสามารถยอมรับได หรือวัดความถูกตองแมนยํา

6. การจดัการโครงแบบของซอฟตแวร (Software Configuration Management) เปนการ

กําหนดกฎเกณฑ เพ่ือกําหนดโครงสรางของซอฟตแวร เง่ือนไข ตลอดจนขอกําหนดในงานท่ีพัฒนา

อาจจะรวมถึงการกําหนดคาเริ่มตนใหกับซอฟตแวร ในสวนท่ีมีความสําคัญ

7. การเตรียมและการผลิต (Work Product Preparation and Production) สวน

นี้เปนอีกสวนท่ีมีความสําคัญเก่ียวกับการพัฒนาซอฟตแวรเพราะกระบวนการนี้ทําใหเห็นภาพรวมของงาน

ทําใหสรางความเขาใจท่ีตรงกันกับลูกคาและผูพัฒนาระบบ

การปรับปรุงกระบวนการดวยซีเอ็มเอ็มไอ

แบบจําลองวุฒิภาวะและความสามารถเชิงบูรณาการ หรือซีเอ็มเอ็มไอ (The Capability

Maturity Model Integration: CMMI) เปนแบบจําลองถูกพัฒนาโดยสถาบันวิศวกรรมซอฟตแวร

(Software Engineering Institute : SEI) โดยมุงหวังเพ่ือเปนการวัดความสามารถขององคกร หนวยงาน

หรือบริษัทพัฒนาซอฟตแวร ซ่ึงจะทําใหทราบวุฒิภาวะของหนวยงานนั้นๆ วาอยูในระดับใด และอาจจะ

เปนแนวทางใหพัฒนาตอไปจนกระท้ังถึงระดับสูงท่ีสุดซ่ึงเปนผลดีกับองคกรและสรางความเชื่อม่ันใหกับ

ลูกคาอีกดวยทางหนึ่ง ซีเอ็มเอ็มไอแบบจําลองซ่ึงกําหนดระดับวุฒิภาวะความสามารถไว 5 ระดับ เชน

วุฒิภาวะระดับท่ี 1 ระดับการเริ่มตน

วุฒิภาวะระดับนี้จะทําการกําหนดเปาหมาย กระบวนการทํางานตางๆ ตลอดจนกิจกรรมท่ีจะตอง

กระทําในโครงการเพ่ือทําการวัดประสิทธิภาพท่ีแนนอน ตลอดจนถึงการกําหนดวิธีการสื่อสารกันระหวาง

สมาชิกในทีมพัฒนาระบบ

18

วุฒิภาวะระดับท่ี 2 ระดับการจัดการ

วุฒิภาวะระดับนี้จําเปนจะตองดําเนินการทุกกิจกรรมในวุฒิภาวะลําดับท่ี 1 ท้ังหมดแลว สวนท่ี

เพ่ิมมาในระดับนี้ เชน กําหนดแผนนโยบายขององคกรสําหรับเปนแนวทางในการปฏิบัติงานของ

กระบวนการใหตรงตามท่ีกําหนดเอาไว เชน แผนการใชทรัพยากรและกระบวนการทํางาน หากมีสิ่งใดท่ีไม

ตรงตามแผนหรือนโยบายท่ีวางเอาไวแลวก็ดําเนินการปรับปรุงใหถูกตอง

วุฒิภาวะระดับท่ี 3 ระดับการกําหนดนิยาม

วุฒิภาวะระดับนี้เนนการกําหนดมาตรฐาน และการดําเนินงานใหตรงกับมาตรฐานท่ีกําหนด อีก

ท้ังยังเก็บขอมูลการวัดและกระบวนการทํางานไวเพ่ือนําไปปรับปรุงกระบวนการทํางานในอนาคต

วุฒิภาวะระดับท่ี 4 ระดับการเชิงปริมาณ

วุฒิภาวะระดับนี้เปนข้ันตอนท่ีพัฒนามาจาก ระดับท่ี3 โดยใชหลักทางสถิติและเทคนิคเชิงปริมาณ

มาใชในการควบคุมการทํางานของกระบวนการทํางานท่ีเล็กลงมา ดําเนินการเก็บขอมูลของแตละ

กระบวนการสําหรบัการปรับปรุงในอนาคต

วุฒิภาวะระดับท่ี 5 ระดับดุลยภาพ

วุฒิภาวะระดับนี้จัดวาเปนระดับสูงท่ีสุด โดยองคกรตองใชกระบวนการวัดคุณภาพของการ

ผลิตภัณฑเปนเครื่องมือท่ีชวยปรับปรุงกระบวนการสําหรับการผลิตซอฟตแวร โดยการปรับปรุงนั้นจะทํา

อยางตอเนื่องและสมํ่าเสมอจนทําใหเกิดความเชื่อม่ันสูงสุดแกลูกคา

การปรบัปรุงกระบวนการดวยซีเอ็มเอ็มไอนั้น เปนเพียงหนึ่งแนวทางในการกําหนดคุณภาพของ

ซอฟตแวรไดในระดับหนึ่งเทานั้น ซ่ึงเปนทางเลือกท่ีเหมาะสมใหหนวยงานหรือองคกรท่ีตองการใชงานเปน

มาตรฐานเดียวกันในการพัฒนาซอฟตแวรท่ีมีคุณภาพ ดวยวิธีการของซีเอ็มเอ็มไอนั้นมีขอสําคัญบาง

ประการเก่ียวกับระดับวุฒิภาวะ โดยจําเปนตองมีกระบวนการตางๆ ตามแตละระดับจึงนับวาเปนผลดีตอ

การพัฒนาซอฟตแวร นอกจากนี้ยังมีอีกหลายเครื่องมือท่ีสามารถนํามาใชเพ่ือปรับปรุงมาตรฐานการผลิต

ซอฟตแวรได อยางเชน ไอทริบเปลอี (IEEE) ซ่ึงนับวาเปนมาตรฐานระดบัโลกในหลายประเทศชั้นนําได

นําเอามาเปนมาตรฐานในการพัฒนาซอฟตแวรอีกดวย

19

วิธีการประเมินตามมาตรฐาน

การประเมินตามแบบซีเอ็มเอ็มไอ เพ่ือปรับปรุงกระบวนการภายใน (CMM-based Appraisal

for Internal Process Improvement – CBA IPI) บวกเทคนิคการวินิจฉัยเพ่ือประเมินความสมบูรณของ

ซอฟตแวร หรือองคกร โดยใชซีเอ็มเอ็มไอเปนฐานสําหรับการประเมิน

สไปช (SPICE หรือ ISO/IEC 15504) เปนมาตรฐานกําหนดสิ่งท่ีตองทําในการประเมิน

กระบวนการของซอฟตแวร

ไอโซ (ISO 9001:2000) เปนมาตรฐานสําหรับองคกรท่ีตองการปรับปรุงคุณภาพโดยรวมของ

ผลิตภัณฑ ระบบหรือบริการ องคกรระหวางประเทศวาดวยการกําหนดมาตรฐาน หรือ ไอโซ

(International Organization for Standardization - ISO) ไดพัฒนามาตรฐาน 9001:2000 เพ่ือผลิต

ผลิตภัณฑท่ีมีคุณภาพดีข้ึน ซ่ึงจะชวยเพ่ิมความพึงพอใจของลูกคา ISO 9001:2000 ไดนําวัฏจักร

“วางแผน-ทํา-ตรวจสอบ-ปฏิบัติ (Plan-Do-Check-Act Cycle)” มาใช โดยอธิบายแตละสวนดังนี้ การ

วางแผน (Plan) เปนการวางวัตถุประสงค กิจกรรม และหนวยงานยอยของกระบวนการทํา (Do) เปนการ

นํากระบวนการของซอฟตแวรไปปฏิบัติ ตรวจสอบ (Check) เปนการตรวจสอบและวัดกระบวนการเพ่ือให

ไดคุณภาพ การปฏิบัติ (Act) เปนการทํากิจกรรมการปรับปุรบกระบวนการของซอฟตแวรแบบจําลอง

กระบวนการสวนบุคคล และทีม (Personal and Team Process Models) กระบวนการของซอฟตแวร

ท่ีดีท่ีสุด คือกระบวนการท่ีเขากับผูคนท่ีจะปฏิบัติงาน ตรงตามความตองการของทีมงาน โดยตองคํานึงถึง

ความตองการในระดับเล็กของแตละสมาชิก และความตองการในระดับใหญขององคกรดวย

รูปแบบของกระบวนการ

การสรางรูปแบบของกระบวนการ เปนวิธีการบอกลักษณะสําคัญของกระบวนการซอฟตแวร

ทีมงานซอฟตแวรสามารถท่ีจะสรางกระบวนการท่ี ตรงตามความตองการของโครงการจากแบบ

กระบวนการตางๆ ท่ีเก่ียวของไดนําเสนอแมแบบ เพ่ือใชอธิบายรูปแบบกระบวนการไวดังนี้

1. ชื่อแบบรูป (Pattern Name) ชื่อแบบรูปแบบจะตองสื่อถึงหนาท่ีการทํางานท่ีเกิดข้ึนภายใน

กระบวนการทํางานของซอฟตแวร เชน การสื่อสารกับลูกคา ฟงกชันการทํางานท่ีสําคัญ

2. ความจํานง (Intent) จําเปนท่ีจะตองมีการระบุวัตถุประสงคไวโดยยอ ตัวอยางเชน ความจํานง

ของการสื่อสารกับลูกคา คือ “เพ่ือสรางความรวมมือกับลูกคาในการพยายามท่ีจะกําหนดขอบขายของ

โครงการ ความตองการทางธุรกิจ และขอจํากัดอ่ืนๆ ของโครงการ”

20

3. ชนิด (Type) ชนิดของรูปแบบ แบงออกไดเปน 3 ชนิด คือ

รูปแบบงานยอย (Task Pattern) เปนตัวกําหนดการกระทํา (Action) ทางดานวิศวกรรม

ซอฟตแวร ซ่ึงเปนสวนหนึ่งของกระบวนการ ตัวอยางแบบรปูงานยอย เชน การรวบรวมความตองการ

รูปแบบข้ัน (Stage Pattern) เปนตัวกําหนดกิจกรรมของกรอบงาน เนื่องจากกิจกรรม

กรอบงานประกอบดวยสวนยอยหลายงาน ซ่ึงสอดคลองกับข้ัน ตัวอยางแบบของข้ัน เชน การสื่อสาร

รูปแบบเฟส (Phase Pattern) เปนตัวกําหนดลําดับของกิจกรรมกรอบงาน ซ่ึงเกิดกับ

กระบวนการ แมแตในกรณีท่ีการไหลของกิจกรรมนั้นมีการทําซํ้า (Iterative) ตัวอยางหนึ่งของแบบรูป

เฟส คือ แบบจําลองแบบเกลียว (Spiral Model) หรือการจัดทําตนแบบโปรแกรม (Prototyping)

4. บริบทตั้งตน (Initial Context) กลาวถึงสภาวะแวดลอมของการท่ีจะนํารูปแบบไปประยุกต

ใชตองการทราบขอมูลดังนี้ (1) มีกิจกรรมท่ีเก่ียวของกับทีม หรือองคกรอะไรบางท่ีเกิดข้ึนแลว (2)

สถานะของกระบวนการในตอนเริ่มตนเปนอยางไร และ (3) สารสนเทศทางวิศวกรรมซอฟตแวร หรือ

สารสนเทศของโครงการอะไรบางท่ีมีอยู

5. ปญหา (Problem) เปนการอธิบายวิธีการแกปญหาโดยใชแบบรูป เชน ปญหาท่ีจะแกไข

โดยแบบรูปการสื่อสารกับลูกคา อาจอธิบายไดดังนี้ การสื่อสารระหวางผูพัฒนากับลูกคาไมเพียงพอ

เนื่องจากไมมีรูปแบบท่ีมีประสิทธิภาพในการซักถามเพ่ือสังเคราะหความตองการของลูกคาได

6. ทางแกปญหา (Solution) ภายหลังท่ีรับทราบถึงปญหา ทีมท่ีพัฒนาระบบจําเปนตอง

กําหนดแนวทางในการแกไข อาจจะหมายถึงการทบทวนกระบวนการเพ่ือสรางความเขาใจกันในทีมและ

ลูกคา

7. บริบทผล (Resulting Context) บรรยายถึงสภาวะท่ีจะเกิดข้ึนภายหลังจากท่ีไดมีการ

นํารูปแบบไปใชอยางประสบผลสาํเร็จ

8. แบบอ่ืนๆ ท่ีเก่ียวของ (Related Patterns) จะบอกถึงรูปแบบกระบวนการอ่ืนๆ ท่ี

สัมพันธ

โดยตรงกับแบบท่ีกลาวถึง อาจเปนในรูปแบบลําดับข้ันหรือไดอะแกรมอ่ืนๆ ประโยชนหรือตัวอยางท่ีได

บรรยายถึงตัวอยางเฉพาะท่ีสามารถนํารูปแบบไปประยุกตใชได

กระบวนการของซอฟตแวรสวนบุคคล

การพัฒนาซอฟตแวรสวนบุคคลนั้น ถือวาเปนกระบวนการท่ีไมซับซอน มีการกําหนดข้ันตอนของ

กิจกรรมเปน 5 กิจกรรม คือ วางแผน การออกแบบข้ันสูง การทบทวนการออกแบบข้ันสูง การพัฒนา

และการตรวจสอบภายหลัง

21

1. การวางแผน กิจกรรมวางแผนนนี้มีความสําคัญเปนอยางมากทําให สามารถแยกแยะความ

ตองการหลักและความตองการรอง และเปนกิจกรรมท่ีชวยประมาณขนาดทรัพยากรท้ังคน เวลา และ

งบประมาณท่ีจําเปนในการพัฒนาซอฟตแวร

2. การออกแบบข้ันสูง กิจกรรมนี้เปนการวางคุณลักษณะของแตละองคประกอบยอยของการ

พัฒนาซอฟตแวร และออกแบบองคประกอบยอยเหลานั้นใหครอบคลุมการใชงาน อีกท้ังตองคํานึงถึง

ความตองการของผูใชงานดวย

3. การทบทวนการออกแบบระดับสูง กิจกรรมนี้ใชวิธีทดสอบอยางมีแบบแผนเพ่ือคนหา

ขอผิดพลาดท่ีอาจจะเกิดข้ึน ผูพัฒนาควรจะสรางตนแบบเพ่ือความเขาใจท่ีตรงกันของท้ังลูกคาและทีมงาน

ทบทวนเง่ือนไข และสิ่งท่ีสําคัญของระบบเพ่ือปองกันขอขัดแยงภายหลัง

4. การพัฒนา กิจกรรมนี้มีการกลั้นกรองงานออกแบบระดับองคประกอบยอยใหดีข้ึนโดย ทําการ

พัฒนาโปรแกรม ดวยภาษาคอมพิวเตอรท่ีทันสมัย และเหมาะสมกับงาน ทําการติดตั้งและทดสอบการใช

งานโปรแกรมอยางตอเนื่อง เพ่ือใหลูกคาพึงพอใจ

5. การตรวจสอบภายหลัง กิจกรรมนี้เปนการประเมินประสิทธิผลโดยตัววัดตางๆ ท่ีเก็บตลอด

กระบวนการ สามารถตรวจสอบไดจากเอกสาร คูมือการติดตั้งและใชงาน

เคร่ืองมือและวิธีที่ใชในกระบวนการพัฒนาซอฟตแวร

เครื่องมือ (Tools) คือซอฟตแวรคอมพิวเตอรท่ีถูกสรางข้ึนมาเพ่ือผลิตซอฟตแวร มีวัตถุประสงค

เพ่ือชวยในกระบวนการทํางานของการผลิตซอฟตแวรใหสะดวกข้ึน เครื่องมือท่ีสรางข้ึนมานี้จะทําหนาท่ี

คอยชวยทํางานท่ีซับซอน อํานวยความสะดวกไดมากยิ่งข้ึน ลดภาระการทํางานของนักวิศวกรซอฟตแวร

ลงไดมาก ฟงกชันสําหรับชวยในการออกแบบ ชวยหาขอผิดพลาด และแกไขไดอยางถูกตอง เครื่องมือ

สามารถจําแนกไดหลายประเภท โดยจําแนกตามหนาท่ีการทํางานฟงกชันและการทํางานรวมกัน

สามารถจําแนกจากกระบวนการทํางานได 8 กลุม ดังนี้

1. เครื่องมือสําหรับวิเคราะหความตองการของระบบเปนเครื่องมือท่ีชวยสรางแบบจําลอง ความ

ตองการของระบบจากผูใชงาน โดยทําหนาท่ีวิเคราะหขอกําหนด และตรวจสอบความตองการดาน

ซอฟตแวร และเครื่องมือในการติดตามความตองการ ทําหนาท่ีติดตามเม่ือความตองการของระบบมีการ

เปลี่ยนแปลง

22

2. เครื่องมือในการออกแบบซอฟตแวร เปนเครื่องมือท่ีทําหนาท่ีสรางซอฟตแวรและตรวจสอบ

ความถูกตองของซอฟตแวรท่ีพัฒนาข้ึน ปจจุบันถูกพัฒนาใหสนับสนุนฟงกชันของการวิเคราะหความ

ตองการของระบบ เชน โปรแกรมรีเลชันแนล โรส (Relational Rose)

3. เครื่องมือสรางซอฟตแวร เปนกลุมของเครื่องมือท่ีชวยสรางซอฟตแวรท้ังหมด เชน เครื่องมือ

แกไขโปรแกรม คอมไพเลอร ดีบักเกอร เปนตน

4. เครื่องมือทดสอบซอฟตแวร เปนกลุมของเครื่องมือท่ีชวยสรางกรณีการทดสอบ สําหรับใช

ทดสอบเหตุการณท่ีอาจจะเกิดข้ึน เครื่องมือสําหรับการประเมินผลการทดสอบเปนการวัดประสิทธิภาพ

การทํางานของซอฟตแวร

5. เครื่องมือสําหรับการบํารุงรักษาซอฟตแวร เปนเครื่องมือท่ีชวยในการคงสภาพของซอฟตแวร

เม่ือผานการใชงานมาระยะหนึ่งแลว เพ่ือใหม่ันใจวาซอฟตแวรยังสามารถใชงานไดอยางดี

6. เครื่องมือจัดการโครงแบบ เปนเครื่องมือท่ีใชติดตามการเปลี่ยนแปลง ทุกองคประกอบของ

ซอฟตแวร การจัดการรุนของการพัฒนาซอฟตแวรตลอดถึงการจัดจําหนายซอฟตแวร

7. เครื่องมือบริหารงานวิศวกรรมซอฟตแวร เปนเครื่องมือท่ีชวยในการบริหารจัดการโครงการ

สําหรับผูบริหารโครงการมีดังนี้ งานสวนของการวางแผนและติดตามโครงการ เครื่องมือวิเคราะหความ

เสี่ยง และเครื่องมือวัดผลสัมฤทธิ์ของโครงการ

8. เครื่องมือคุณภาพของซอฟตแวร เปนเครื่องมือท่ีทําหนาท่ีตรวจสอบคุณภาพของซอฟตแวร

และเครื่องมือในการวิเคราะหคุณภาพของซอฟตแวร เชน การควบคุมกระบวนการการทํางาน (Control

Flow)

บทสรุป

กระบวนการพัฒนาซอฟตแวรเทคโนโลยีแบบชั้นนั้นเปนอีกข้ันตอนหนึ่งของการพัฒนาซอฟตแวร

ท่ีสําคัญ ผูพัฒนาจําเปนจะตองยึดหลักวงจรการพัฒนาระบบเพ่ือใหบรรลุตามวัตถุประสงค จะเห็นวามี

กิจกรรมท่ีเกิดข้ึนระหวางการพัฒนาซอฟตแวรจําเปนตองมีกระบวนการ และการปรับปรุงกระบวนการ

ดวยซีเอ็มเอ็มไอ เปนท่ีนิยมใชกันอยางแพรหลายสําหรับควบคุมกระบวนการทํางาน ลดปญหาท่ีอาจจะ

เกิดข้ึนระหวางการพัฒนาซอฟตแวร จะเห็นวาทุกข้ันตอนการพัฒนานั้นสามารถปรับเปลี่ยน ยืดหยุนการ

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

พัฒนาซอฟตแวร รวมถึงกระบวนการซอฟตแวรสวนบุคคลดวย ในบางโครงการท่ีมีคุณลักษณะเฉพาะทํา

ใหมีการปรับเปลี่ยนกิจกรรม จําเปนตองเลือกเครื่องมือและวิธีใชในกระบวนการพัฒนาซอฟตแวร เพ่ือให

23

สอดคลองกับกระบวนการทํางานจริงของโครงการ เครื่องมือท่ีชวยในการพัฒนาซอฟตแวร มีสวนสําคัญทํา

ใหการพัฒนาซอฟตแวรมีประสิทธิภาพมากยิ่งข้ึน การเลือกใชเครื่องมือและวิธีท่ีใชในกระบวนการพัฒนา

ซอฟตแวรจึงตองคํานึงถึงขนาดของซอฟตแวรท่ีตองการพัฒนา ความซับซอนของระบบในการออกแบบ

หากใชเครื่องมือท่ีเหมาะสมจะชวยใหการทํางานงายข้ึน


1. จงอธิบายจุดมุงหมายของการพัฒนาซฮฟตแวร

2. จงอธิบายความสําคัญของกิจกรรมท่ีเกิดข้ึนในการพัฒนาซอฟตแวร

3. จงอธิบายความสําคัญของซีเอ็มเอ็มไอ ในระดับตางๆ

4. จงอธิบายหนวยงาน หรือบริษัทท่ีใชซีเอ็มเอ็มไอ ในระดับตางๆ

5. จงอธิบายโดยแสดงตารางเปรียบเทียบ วิธีการประเมินมาตรฐานกับวิธีการพัฒนาซอฟตแวรแต

ข้ันตอนมีความสําคัญอยางไร

6. จงอธิบายวัตถุประสงคของการใชงานเครื่องมือ

7. จงอธิบายความสําคัญของเครื่องมือท่ีมีตอกระบวนการของซอฟตแวรสวนบุคคล

8. จงอธิบายกระบวนการของซอฟตแวรสวนบุคคลมีกิจกรรมใดบาง

9. จงศึกษาคนควาเพ่ิมเติมเก่ียวกับ ISO 9001:2000

10. จงศึกษาคนควาเพ่ิมเติมเก่ียวกับหนวยงานในประเทศไทย ท่ีทําหนาท่ีดูแลควบคุมการพัฒนา


24

อางอิง






(มหาชน).



Roger S. Pressman. (2005). Software Engineering. (6th ed.). Mc-Graw-Hill.



Software Park. (2006). มาตรฐานกระบวนการในการพัฒนางาน (CMMI). [online] คนวันท่ี 11

มก ราคม 2559, จากhttp://www.swpark.or.th/cmmiproject/index.php/general/7 3 -

what-cmmi.

25



1. แบบจําลองน้ําตก

2. แบบจําลองกระบวนการคอยเพ่ิมข้ึน

3. แบบจําลองลําดับเชิงเสน

4. แบบจําลองตนแบบ

5. แบบจําลองเรงรัด

6. แบบจําลองสไปรัล

7. แบบจําลองการพัฒนาไปพรอมกัน

8. แบบจําลองกระบวนการยนูิฟายด


1. นักศึกษาสามารถอธิบายความหมาย ความสําคัญของแบบจําลองกระบวนการพัฒนาระบบ

เชน แบบจําลองน้ําตก แบบจําลองกระบวนการคอยเพ่ิมข้ึน แบบจําลองลําดับเชิงเสน แบบจําลองตนแบบ

แบบจําลองเรงรัด แบบจําลองสไปรัล แบบจําลองการพัฒนาไปพรอมกัน แบบจําลองกระบวนการยูนิ

ฟายดได

2. นักศึกษาสามารถอธิบายกระบวนการการทํางานของแบบจําลองตางๆ ได

3. นักศึกษาสามารถอธิบาย จุดเดนจุดดอย รวมถึงงานท่ีเหมาะสมกับแบบจําลองตางๆ ได

วิธีสอนและกิจกรรมการเรียนการสอน


1.1 วิธีการสอนแบบบรรยาย เริ่มจากอธิบายความหมาย ความสําคัญของแบบจําลอง

กระบวนการพัฒนาระบบ เชน แบบจําลองน้ําตก แบบจําลองกระบวนการคอยเพ่ิมข้ึน แบบจําลองลําดับ

เชิงเสน แบบจําลองตนแบบ แบบจําลองเรงรัด แบบจําลองสไปรัล แบบจําลองการพัฒนาไปพรอมกัน

และแบบจําลองกระบวนการยูนิฟายด



26


2.1 แสดงตัวอยางกระบวนการการทํางานของแบบจําลองตางๆ

2.2 แบงกลุมอภิปรายเรื่องแบบจําลองการพัฒนาซอฟตแวรเชิงแงมุม










27

บทท่ี 3

แบบจําลองกระบวนการพัฒนาระบบ

ในบทนี้กลาวถึงการพัฒนาซอฟตแวรใหมีคุณภาพและตรงตามความตองการของผูใชนั้น ถือวา

เปนสิ่งท่ีสําคัญมากดังนั้น จึงมีแบบจําลองกระบวนการพัฒนาระบบหรือแบบจําลองการผลิต ซ่ึง

แบบจําลองนี้มีหนาท่ีในการสรางรูปแบบ โดยการจําลองกระบวนการผลิตท่ีซับซอนเพ่ือลดความเสี่ยงท่ี

อาจจะเกิดข้ึนระหวางการพัฒนาระบบ สรางความเขาใจท่ีถูกตองตรงกันกับลูกคา แบบจําลองการผลิต

ซอฟตแวรนั้นอาจจะแตกตางกันไปตามลักษณะของงานท่ีพัฒนา เชน แบบจําลองน้ําตก แบบจําลอง

กระบวนการคอยเพ่ิมข้ึน แบบจําลองเชิงเสน แบบจําลองตนแบบ แบบจําลองเรงรัด แบบจําลองสไปรัล

แบบจําลองการพัฒนาไปพรอมกันและแบบจําลองกระบวนการยูนิฟายด

แบบจําลองน้ําตก

แบบจําลองนี้เปนท่ีนิยมอยางแพรหลายเนื่องจากสามารถทําความเขาใจไดงายการทํางานเริ่มเปน

กระบวนการ โดยแบงออกเปน 5 ข้ันตอนการดังนี้

ข้ันตอนท่ี 1 กําหนดความตองการของระบบ เปนกระบวนการแรกสุดของการทําแบบจําลอง

จุดประสงคเพ่ือวิเคราะหความตองการของระบบท่ีมีอยูอยางแทจริง

ข้ันตอนท่ี 2 การออกแบบซอฟตแวรระบบ เปนการออกแบบทางตรรกะของระบบ การทํางาน

หลักและการทํางานสวนระบบยอย

ข้ันตอนท่ี 3 การลงมือทํา เปนการทําตามแบบท่ีไดเตรียมไว นักพัฒนาโปรแกรมจะเลือกใช

เครื่องมือท่ีเหมาะสมกับการพัฒนาโปรแกรม

ข้ันตอนท่ี 4 การประสานระบบและการทดสอบ หากระหวางข้ันตอนท่ีสามไดมีการแยกสวน

เพ่ือการพัฒนาระบบ ในข้ันตอนท่ี 4 นี้จะนําระบบท่ีพัฒนามารวมกัน และเริ่มกระบวนการทดสอบระบบ

ยอย จนกระท้ังการทดสอบเสร็จสิ้นทุกระบบ

ข้ันตอนท่ี 5 การนําไปใชและการบํารุงรักษา ภายหลังจากการสงมอบระบบแลวนั้นผูพัฒนา

จะตองทําแผนการปรับปรุงดูแลรักษาระบบอยูระยะหนึ่งเพ่ือสรางความเชื่อม่ันใหกับลูกคาและบริการหลัง

การขาย

กระบวนการขางตนอาจจะเรียกวา วงจรชีวิต (Life Cycle) ซ่ึงหมายถึง แบบระเบียบวิธี

เรียงลําดับเปนระบบในการพัฒนา อยางไรก็ตามแบบจําลองน้ําตกนี้ยังมีจุดท่ีพบวาเปนปญหาสําหรับ

ผูพัฒนาระบบท่ีมีขอบเขตท่ีใหญมาก อยางท่ีทราบกันวา แบบจําลองน้ําตกนั้นมีข้ันตอนท่ีเปนลําดับดังนี้

การทํางานจึงมีการสงมอบงาน การทํางานเปนลําดับข้ัน ซ่ึงบางครั้งอาจจะทําใหเกิดความลาชาของงานใน

28

บางสวนสงผลใหระยะเวลารวมในการทํางานชาเกินกําหนด อีกประการหนึ่งคือหากตองการแกไขหรือเพ่ิม

งานในสวนข้ันตอนท่ีผานมาแลว แบบจําลองนี้อาจจะไมรองรับการทํางานแบบวนซํ้าไปมา ดังภาพท่ี 3.1

ภาพท่ี 3.1 แสดงแบบจําลองน้ําตก

แบบจําลองกระบวนการคอยเพ่ิมข้ึน

ในบางครั้งเกิดสถานการณท่ีความตองการเริ่มแรกของลูกคามีความชัดเจน แตขอบเขตงานท่ัวไป

ไมอาจกําหนดไมแนนอน มีการแกไขปรับปรุงอยูตลอดเวลา หรือความรีบเรงท่ีตองการใชซอฟตแวรอยาง

มากทําใหตองผลิตคูขนานกับการใชงาน ดังนั้นจึงจําเปนตองมีการผสมสวนประกอบของแบบจําลองน้ําตก

ประยุกตกับการทําวนทําใหเกิดแบบจําลองกระบวนการคอยเพ่ิมข้ึน โดยการผลิตซอฟตแวรรุนแรกของ

ผลิตภัณฑ หรือเปนเวอรชัน ซ่ึงในการทํางานตามแบบจําลองคอยเพ่ิมข้ึนนี้ มีการพัฒนาและใหทดลองใช

วนกลับมาปรับปรุงหรือเพ่ิมสวนท่ีตองการอีกครั้ง ทําเชนนั้นวนไป ดังภาพท่ี 3.2

ภาพท่ี 3.2 แสดงแบบจําลองกระบวนการคอยเพ่ิมข้ึน

29

แบบจําลองนี้อาจจะเหมาะกับงานท่ีมีขนาดเล็ก ผูใชมีการใชงานและปรับปรุงพัฒนาไปดวยกันกับ

ผูพัฒนาระบบ ผลสุดทายจะไดซอฟตแวรท่ีเปนรุนใหม หรือรุนมาตรฐาน และเปนขอไดเปรียบของ

แบบจําลองกระบวนการคอยเพ่ิมข้ึน

แบบจําลองลําดับเชิงเสน

แบบจําลองนี้เปนแบบจําลองดั้งเดิม เนนการเชื่อมโยงของกิจกรรมท่ีทําโดยเรียงลําดับกิจกรรม

ตางๆ เอาไวอยางชัดเจน การทํางานเปนแบบเรียบงายทําตามลําดับกอนหลังชัดเจนสงผลใหการพัฒนา

ซอฟตแวรมีคุณภาพอยางมากก็ตอเม่ือมีความตองการของระบบท่ีชัดเจน มีการปรับปรุงเปลี่ยนแปลงเพียง

เล็กนอยเทานั้น ดังภาพท่ี 3.3

ภาพท่ี 3.3 แสดงแบบจําลองลําดับเชิงเสน

แบบจําลองตนแบบ

ในบางครั้งท่ีการพัฒนาซอฟตแวรไมมีความตองการของระบบท่ีชัดเจน เชน การพัฒนาซอฟตแวร

ใหกับบางหนวยงานท่ีไมคุนเคยกับคอมพิวเตอร นักพัฒนาซอฟตแวรจําเปนตองคิดตนแบบ เพ่ือใหผูใชเห็น

ภาพของระบบงานท่ีชัดเจนมากท่ีสุด และในอีกทางหนึ่ง การทําตนแบบเพ่ือเปนการยืนยันกับลูกคาในสิ่งท่ี

ตองการพัฒนาระบบ สงผลท่ีดีตอการทําความเขาใจรวมกันอีกดวย ดังภาพท่ี 3.4

ภาพท่ี 3.4 แสดงแบบจําลองตนแบบท่ีใชงานรวมกับแบบจําลองน้ําตก

30

แบบจําลองเรงรัด

เปนแบบจําลองกระบวนการซอฟตแวร แบบเพ่ิมข้ึนเปนทวีคูณเพ่ือใหบรรลุถึงเปาหมายเดียวกัน

โดยใชเวลาอันสั้น วธิีการท่ีแพรหลายคือการแบงงานออกเปนสวนๆ และกระจายกันพัฒนา เม่ือครบตาม

กําหนดเวลาท่ีตกลงกันก็นํามารวมประกอบกันเปนซอฟตแวรท่ีตองการ จุดดอยของแบบจําลองนี้อาจจะ

ไมเหมาะกับโครงการขนาดเล็ก ซ่ึงวิธีนี้จําเปนตองมีทรัพยากรบุคคลจํานวนมากเพ่ือแบงเปนทีมหลายๆ

ทีม ยกเวนโครงการท่ีไมสามารถขยายสวนได และโครงการอาจลมเหลวไดงายถาหากระบบท่ีแยกกัน

พัฒนาเม่ือนํากลับมารวมกันแลว ไมสามารถท่ีจะทํางานรวมกันไดดังนั้นขอจํากัดอยางหนึ่งของแบบจําลอง

นี้จําเปนตองมีการกําหนดเง่ือนไข หรือขอบเขตการพัฒนาระบบตลอดจนเครื่องมือท่ีพัฒนาอยางชัดเจน

เพ่ือปองกันปญหาการไมเขากันของระบบ

แบบจําลองสไปรัล

เปนแบบจําลองกระบวนการเชิงววิัฒนท่ีรวมเอาลักษณะวนซํ้าของการสรางตนแบบกับการทํางาน

อยางเปนข้ันตอน และมีการควบคุมของแบบจําลองน้ําตกเขาดวยกัน ดังนั้น ซอฟตแวรท่ีพัฒนาดวย

แบบจําลองสไปรัล จะพัฒนาออกมาเปนชวงๆ ท่ีมีวิวัฒนาการในชวงหลังๆ ผลผลิตจะเปนซอฟตแวร

เวอรชันท่ีสมบูรณมากข้ึน แบบจําลองสไปรัล เหมาะสมกับการพัฒนาระบบขนาดใหญ เพราะซอฟตแวร

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

ไปรัล คือลูกคาอาจไมม่ันใจวาจะควบคุมกระบวนการเชิงวัวัฒนได นอกจากนี้การพิจารณาความเสี่ยง

ข้ึนอยูกับการประเมินของผูเชี่ยวชาญ ดังภาพท่ี 3.5

ภาพท่ี 3.5 แสดงแบบจําลองสไปรัล

ท่ีมา: https://techspirited.com/spiral-model-in-software-development

31

แบบจําลองการพัฒนาไปพรอมกัน

แบบจําลองการพัฒนาไปพรอมกัน บางครั้งถูกเรียกวา วิศวกรรมไปพรอมกัน สามารถแสดง

ข้ันตอนอยางเปนระบบดวย ชุดของกิจกรรมกรอบงาน กิจกรรมและงานยอยทางวิศวกรรมซอฟตแวร และ

สถานะท่ีผูกติดกับกิจกรรมและงานยอยเหลานั้น แบบจําลองนี้ประยุกตไดกับการพัฒนาซอฟตแวรทุกชนิด

และแสดงใหเห็นภาพสถานะปจจุบันของโครงการ แทนท่ีจะมองงานยอยกิจกรรมเปนลําดับของเหตุการณ

ก็มองเปนโครงขายของกิจกรรม ท่ีทุกงานและงานยอยในโครงขายเกิดข้ึนพรอมๆ กัน

แบบจําลองกระบวนการยูนิฟายด

แบบจําลองกระบวนการยูนิฟายด เปนความพยายามดึงเอาลักษณะท่ีดีท่ีสุดของกระบวนการ

ดั้งเดิมออกมา แตปรับใชในลักษณะท่ีอิมพลิเมนต ไดนําหลักการของการพัฒนาซอฟตแวรอาไจลมารวม

กับแบบ จําลองกระบวนการยูนิฟายด ประกอบดวยกิจกรรมงานท่ัวไป 5 ระยะดังนี้

เฟสระยะเริ่มตน ประกอบดวยสื่อสารกับลูกคา และกิจกรรมวางแผนการคุยกับลูกคาและผูใชงาน

จะทําใหสามารถระบุความตองการทางธุรกิจ นําเสนอสถาปตยกรรมอยางคราวๆ และวางแผนโครงการใน

ลักษณะวนซํ้าและคอยเพ่ิมข้ึนได ยูสเคสบงบอกลักษณะและหนาท่ีการทํางานสําหรับกลุมผูใชแตละกลุม

ท่ีเรียกวา แอคเตอร แอคเตอรเปนผูท่ีมีปฏิสัมพันธกับระบบโดยยูสเคสชวยกําหนดขอบเขตของโครงการ

และเปนพ้ืนฐานสําหรับการวางแผนโครงการ

เฟสระยะขยายรายละเอียด ปรับปรุงยูสเคสเบื้องตนท่ีไดสรางข้ึนในเฟสระยะเริ่มตน และขยาย

สถาปตยกรรมใหครอบคลุมมุมมองท้ังหาของซอฟตแวรเชน แบบจําลองยูสเคส แบบจําลองการวิเคราะห

แบบจําลองการออกแบบ แบบจําลองการอิมพลิเมนต และแบบจําลองการใชงาน นอกจากนี้จะมีการ

ทบทวนการวางแผนงานอยางรายละเอียดในตอนทายของเฟสเพ่ือใหม่ันใจในขอบเขตงานความเสี่ยง และ

กําหนดวันสงมอบ วายังทําไดตามกําหนด

เฟสระยะกอสราง มีกิจกรรมกอสรางเชนเดียวกับท่ีกําหนดสําหรับกระบวนการซอฟตแวรท่ัวไป มี

การพัฒนาจัดหาคอมโพเมนทท่ีทํางานตามยูสเคสได

เฟสระยะสงมอบ ประกอบดวยระยะทายๆ ของกิจกรรมกอสรางและระยะตนของกิจกรรมการใช

งานผูใชจะไดรับซอฟตแวรเพ่ือทดสอบรุนแรก หากลูกคาพึงพอใจกับการใชงานถือวาเปนสิ่งท่ีประสบ

ความสําเร็จในการพัฒนาซอฟตแวร

เฟสระยะการทํางาน มีกิจกรรมการใชงานท่ัวไปมีการเฝาดูการใชงานการสนับสนุนชวยเหลือ

และการรายงานจุดบกพรอง พรอมท้ังมีการรองขอใหปรับปรุงและประเมินคํารองขอ

32

โดยกระบวนการยูนิ ฟายด ให ความสํ า คัญ กับการสื่ อสารลูกค า เริ่มจากการสื่ อสาร

(Communication) พูดคุยซักถามถึงความตองการของระบบ วางแผน (Planning) เม่ือไดพูดคุยถึงความ

ตองการท่ีแทจริงของระบบแลวจึงนําขอมูลสารสนเทศท่ีไดมาวางแผนงาน เพ่ือใหเห็นภาพโดยรวมท้ังหมด

ของการพัฒนาซอฟตแวร เลือกแบบจําลอง (Modeling) ท่ีคิดวาเหมาะสมกับกระบวนการในการพัฒนา

ซอฟตแวรครั้งนี้ ท้ังนี้ข้ึนอยูกับขนาดของซอฟตแวรท่ีพัฒนา การสงตอใหนักพัฒนาไดสรางซอฟตแวรดวย

โปรแกรมภาษาคอมพิวเตอร (Construction) เม่ือพัฒนาซอฟตแวรไประยะหนึ่งจําเปนจะตองทดสอบการ

ใชงานและปรับปรุงสวนท่ีมีขอผิดพลาดเพ่ือเปนการปรับใชงานซอฟตแวรใหมีประสิทธิภาพท่ีสุด

(Deployment) เม่ือไดซอฟตแวรท่ีตรงกับความตองการแลวจึงสงมอบใหกับลูกคาตอไป (Software

increment) ดังภาพท่ี 3.6

ภาพท่ี 3.6 แสดงแบบจําลองยูนิฟายด

ท่ีมา: http://slideplayer.com/slide/3890408/

บทสรุป

แบบจําลองกระบวนการซอฟตแวรนั้น มีสวนสําคัญทําใหซอฟตแวรมีคุณภาพ สามารถเลือก

แบบจําลองไดตามคุณลักษณะของซอฟตแวร เชน แบบจําลองน้ําตก ซ่ึงเปนแบบจําลองท่ีมีชื่อเสียงในเรื่อง

ของความชัดเจนของข้ันตอนการทํางาน แบบจําลองกระบวนการคอยเพ่ิมข้ึน มักใชสําหรับซอฟตแวรท่ีมี

การพัฒนาอยางตอเนื่องมีการปรับปรุงอยูตลอดเวลา แบบจําลองลําดับเชิงเสน เนนไปท่ีกระบวนการแบบ

เสนตรง หาตองการสรางภาพของซอฟตแวรใหเห็นอยางชัดเจน ควรเลือกใชแบบจําลองตนแบบ

แบบจําลองเรงรัดใชในกรณีเรงดวน และซอฟตแวรมีขนาดไมใหญมากนักใชคนนอย ความซับซอนไมมาก

นัก ในงานท่ีมีความซับซอนสูงและมีทีมงานมากควรใชแบบจําลองสไปรัล จุดเดนคือมีกระบวนการ

วิเคราะหเพ่ือปองกันขอผิดพลาดไดเปนอยางดี แบบจําลองการพัฒนาไปพรอมกัน เนนท่ีการพัฒนา

ซอฟตแวรไปพรอมกัลลูกคา ตางฝายตางเรียนรูและปรับเขาหากันจนงานสําเร็จ แบบจําลองกระบวนการ

33

ยูนิฟายดเปนแบบจําลองท่ีเนนกระบวนการพูดคุยสื่อสารกันตลอดการพัฒนาซอฟตแวร แบบจําลอง

ท้ังหมดนั้นมีคุณสมบัติท่ีแตกตางกัน ดังนั้นจึงมีความจําเปนท่ีจะตองทําความเขาใจหลักการของการพัฒนา

ซอฟตแวร การเลือกใชกระบวนการ เลือกกิจกรรมใหเหมาะสมสอดคลองกับซอฟตแวรท่ีตองการจะ

พัฒนา นักวิศวกรซอฟตแวรควรจะตองเลือกใชแบบจําลองกระบวนการท่ีเหมาะสม และกิจกรรมท่ี

สอดคลองกันเปนผลดีตอการพัฒนาซอฟตแวรท่ีดีมีคุณภาพ


1. จงอธิบายความสําคัญของการเลือกรูปแบบของแบบจําลองเพ่ือใชงานใหเหมาะสมกับ

การพัฒนาซอฟตแวรใหมีคุณภาพสูงสุด

2. จงอธิบายและยกตัวอยางแบบจําลองท่ีเหมาะสมกับรูปแบบของการพัฒนาซอฟตแวรท่ีมี

ขนาดเล็ก และมีการเปลี่ยนแปลงความตองการอยูตลอดเวลา

3. จงอธิบายข้ันตอนการทํางานของแบบจําลองน้ําตก

4. จงอธิบายข้ันตอนการทํางานของแบบจําลองกระบวนการคอยเพ่ิม

5. จงอธิบายข้ันตอนการทํางานของแบบจําลองลําดับเชิงเสน

6. จงอธิบายข้ันตอนการทํางานของแบบจําลองตนแบบ

7. จงอธิบายข้ันตอนการทํางานของแบบจําลองเรงรัด

8. จงอธิบายข้ันตอนการทํางานของแบบจําลองสไปรัล

9. จงอธิบายข้ันตอนการทํางานของแบบจําลองการพัฒนาไปพรอมกัน

10. จงอธิบายข้ันตอนการทํางานของแบบจําลองกระบวนการยูนิฟายด

34

อางอิง






(มหาชน).







มกราคม 2559, จากhttp://www.swpark.or.th/cmmiproject/index.php/general/73-

what-cmmi.

Nabil Mohammed Ali Munassar, "A Comparison Between Five Models Of Software

Engineering",Publication in IJCSI International Journal of Computer

ScienceISSN(Online):1694-0814, Issues, Vol.7, Issue5, September2010.

35



1. ความสําคัญของกระบวนการอาไจล

2. กําหนดกฎ 12 ขอของวิธีการอาไจล

3. กระบวนการอาไจลจัดการกับโครงการซอฟตแวรสวนใหญ

4. ปจจัยดานบุคคลของอาไจล

5. เอ็กชทรีม โปรแกรมม่ิง – เอ็กซพี

6. การพัฒนาซอฟตแวรแบบปรับตัว-เอเอสดี

7. วิธีการประมาณการพัฒนาซอฟตแวร


1. นักศึกษาสามารถอธิบายความหมาย กระบวนการอาไจล กําหนดกฎ 12 ขอของวิธีการอา

ไจล กระบวนการอาไจลจัดการกับโครงการซอฟตแวรสวนใหญ ปจจัยดานบุคคลของอาไจล เอ็กช-ทรีม

โปรแกรมม่ิง – เอ็กซพี การพัฒนาซอฟตแวรแบบปรับตัว-เอเอสดี วิธีการประมาณการพัฒนาซอฟตแวร

2. นักศึกษาสามารถอธิบาย จุดเดนจุดดอย ของกระบวนการพัฒนาซอฟตแวรในแบบตางๆ ได

3. นักศึกษาสามารถหาวิธีการประมาณการพัฒนาซอฟตแวรได



1.1 วิธีการสอนแบบบรรยาย เริ่มจากอธิบายความหมาย กระบวนการอาไจล กําหนด

กฎ 12 ขอของวิธีการอาไจล กระบวนการอาไจลจัดการกับโครงการซอฟตแวรสวนใหญ ปจจัยดาน

บุคคลของอาไจล เอ็กช-ทรีม โปรแกรมม่ิง – เอ็กซพี การพัฒนาซอฟตแวรแบบปรับตัว-เอเอสดี วิธีการ

ประมาณการพัฒนาซอฟตแวรได




1.4 แสดงตัวอยางคํานวณหาวิธีการประมาณการพัฒนาซอฟตแวร

1.5 แบงกลุมอภิปรายเรื่องกระบวนการอาไจลจัดการกับโครงการซอฟตแวรสวนใหญ


36









37

บทท่ี 4

กระบวนการอาไจล

ในบทนี้จะกลาวถึงกระบวนการพัฒนาซอฟตแวร ซ่ึงมุงเนนสรางความพึงพอใจใหกับลูกคาเปน

หลัก ดังนั้นจึงเกิดรูปแบบวิธีกระบวนการอาไจล เพ่ือมาตอบสนองกระบวนการงาน เปนแนวทางคิดท่ี

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

ไดซอฟตแวรท่ีใชงานไดตรงตามความตองการ กระบวนการอาไจลนั้นอาศัยกฎ 12 ขอ การสงมอบ

ซอฟตแวรใหลูกคาตรงเวลา นอกจากนี้ปจจัยดานบุคคลของอาไจลสามารถทําใหการพัฒนาซอฟตแวร

บรรลุวัตถุประสงค การพัฒนาแบบเอ็กซ-ทรีม โปรแกรมม่ิง-เอ็กซพี และการพัฒนาซอฟตแวรแบบ

ปรับตัว-เอเอสดี เปนอีกทางเลือกหนึ่งสําหรับนักนักวิศวกรซอฟตแวรไดพิจารณา สุดทายคือการ

ประมาณการพัฒนาซอฟตแวรเพ่ือใหทราบถึงความยากงายของซอฟตแวรเพ่ือบริหารจัดการตอไป

ความสําคัญของกระบวนการอาไจล

ปจจุบันกระบวนการท่ีเปนท่ียอมรับนั้นมีอยูมากมายสําหรับการพัฒนาโปรแกรม กระบวนการอา

ไจลเปนกระบวนการหนึ่งท่ีพัฒนาซอฟตแวรไดอยางมีประสิทธิภาพ เหตุผลท่ีสําคัญคือมีการสื่อสารกัน

อยางเปนระบบ มีกระบวนการทํางานแบบวนซํ้า แบงการออกแบบซอฟตแวรโดยท่ีไมทําการออกแบบ

เพียงครั้งเดียวจบหมด แบงสวนในการตรวสอบ มีการพูดคุยท้ังเปนทางการและไมเปนทางการเพ่ือเชื่อม

ความสัมพันธกับลูกคา ดังภาพท่ี 4.1

ภาพท่ี 4.1 แสดงวิธีการอาไจล

ท่ีมา : http://masterofproject.com/blog/130302/agile-frameworks-methodologies

38

กําหนดกฎ 12 ขอของวิธกีารอาไจล

การทํางานรวมกันเปนทีมนั้นจําเปนตองมีโครงสรางของทีมงานตลอดจนทัศนคติท่ีตองสื่อสาร

ระหวางกัน การทํางานรวมกันเปนทีมนั้นจําเปนตองอาศัยกฏของอาไจล ดังนี้

1. จุดประสงคหลักของการพัฒนาซอฟตแวรดวยกระบวนการอาไจลนี้จําเปนตองมีการสงมอบ

ตรงตามท่ีกําหนดและมีประสิทธิภาพท่ีสุด

2. มีกระบวนการในการปรับปรงุเปลี่ยนแปลงอยูตลอดเวลา ถึงแมวาจะผานไปหลายข้ันตอน

แลวก็ตาม หากจําเปนท่ีจะตองกลับมาทําซํ้าก็ตองทํา

3. กระบวนอาไจลจะทยอยสงมอบงานใหกับลูกคาไดตรวจสอบในเวลาอันสั้น

4. ทีมพัฒนาและลูกคาตองทํางานรวมกันอยูทุกข้ันตอน

5. ทีมงานจําเปนจะตองมีผูท่ีทัศนคติท่ีดีอยูในโครงการ มีการเตรียมการสนับสนุนและเตรียม

สภาพแวดลอมและความเชื่อม่ันวาเขาจะทํางานไดสําเร็จ

6. การวัดประสิทธิภาพการทํางานของซอฟตแวรคือความกาวหนาของโครงการ

7. ทีมงาน ผูใหทุน ผูพัฒนา และผูใชงานควรจะรวมมือกันทํางาน

8. การใหความสําคัญกับทุกข้ันตอนการทํางาน มีสวนชวยใหวิธีการอาไจลประสบความสําเร็จ

มากยิ่งข้ึน

9. การออกแบบท่ีเรียบงาย เปนศิลปะอยางหนึ่งของกระบวนการทํางาน

10. การมีสถาปตยกรรม ระบุความตองการ และงานออกแบบท่ีดีท่ีสุด

11. ทีมงานท่ีดีมีความสามารถสงผลใหการทํางานออกมาไดอยางมีประสิทธิภาพมาก

กระบวนการอาไจลจัดการกับโครงการซอฟตแวรสวนใหญ

กระบวนการอาไจลนั้นมีความสําคัญกับการจัดการโครงการขนาดใหญ เพราะโครงการท่ีมีขนาด

ใหญทําใหมีผูรวมลงทุนหลากหลายและขอบเขตของงานจึงซับซอนไปดวย โดยมีแนวคิดเก่ียวกับการ

บริหารจัดการกระบวนการอาไจล ดังนี้

1. การคาดเดาวาซอฟตแวรท่ีพัฒนาข้ึนมานั้น จะคงอยูตลอดไปแตสามารถท่ีจะกําหนดการ

เปลี่ยนแปลงไปเม่ือความตองการของลูกคาเปลี่ยนแปลงไป

2. ในหลายๆ ครั้งของการพัฒนาซอฟตแวรพบวามีความซํ้าซอนอยู จึงจําเปนท่ีจะตองรวมกัน

เพ่ือใหการทํางานท่ีสมบูรณ ดังนั้นเปนเรื่องยากท่ีจะทํานายวาควรออกแบบอยางไรใหดีท่ีสุด

3. การวิเคราะห ออกแบบ กอสราง และทดสอบ มักจะไมสามารถคาดเดาไดอยางท่ีตองการ

จากมุมมองของการวางแผนท้ังหมด การปรับปรุงเปลี่ยนแปลงตางหากท่ีจะทําใหประสบความสําเร็จ

39

ปจจัยดานบุคคลของอาไจล

การพัฒนาซอฟตแวรท่ีตองการความยืดหยุนสูงเหมาะอยางยิ่งท่ีจะใชแบบจําลองนี้ ปจจัย

ดังตอไปนี้จะมีความสําคัญกับดานตางๆ ดังจะอธิบายตอไปนี ้

1. มีความสามารถ (Competence) หมายถึงความสามารถ ความเชี่ยวชาญในดานใดดาน

หนึ่งท่ีโดดเดน ซ่ึงรวมถึงความเฉลียวฉลาด มีสัญชาตญาณท่ีดี ทักษะการทํางานเปนทีมก็มีความสําคัญเปน

อยางมาก

2. มีเปาหมายรวมกัน (Common Focus) ทุกคนควรมีเปาหมายหนึ่งเดียวกันคือการพัฒนา

ซอฟตแวรอยางไรใหมีประสิทธิภาพมากท่ีสุด ถึงแมจะพบปญหาบางระหวางการพัฒนา แตหากทุกคน

กําหนดเปาหมายเดียวกันก็จะทําใหผานพนไปได

3. มีความรวมมือกัน (Col laborat ion) วิศวกรรมซอฟตแวรไมวาจะใชกระบวนการใดก็ตาม

การสื่อสารกันในทีมและลูกคาเปนสิ่งท่ีจําเปนจะตองทํา เพ่ือความสําเร็จของงาน

4. มีความสามารถในการตัดสินใจ (Decis ion-making Abil ity) การตัดสินใจกันระหวาง

ทีมงาน การใหความสําคัญกับผูท่ีตัดสินใจก็เปนอีกสวนท่ีสําคัญ

5. ความสามารถในการแกปญหาท่ีคลุมเครือ (Fuzzy Problem-solving Ability) ผูจัดการ

จะตองระลึกไวเสมอวา ลูกคามีความตองการเปลี่ยนแปลงบอยๆ ในบางครั้ง ทีมงานตองยอมรบัความจริง

วาปญหาท่ีพบและแกไขไดทุกๆ ครั้ง

6. ความเชื่อใจและเคารพซ่ึงกันและกัน (Mutual Trust and Respect) ทีมงานจําเปนอยาง

ยิ่งท่ีจะตองรวมใจกันเปนหนึ่งเดียวในการทํางานรวมกัน

เอ็กชทรีม โปรแกรมมิ่ง – เอ็กซพี

ถูกคิดคนโดย Kent Beck ในป 1999 มักจะใชเปนแนวทางในการพัฒนาเชิงวัตถุ โดยมีชุดของกฎ

และขอปฏิบัติท่ีตองทําระหวางกิจกรรมกรอบงานท้ังหมด 4 ข้ันตอน

1. การวางแผน กิจกรรมการวางแผนเริ่มตน นอกจากนักวิเคราะหและทีมงานท้ังหมดจะเก็บ

รวบรวมความตองการของลูกคาท้ังหมดแลวนั้น ยังจะตองหาวิธีคิดตนทุนในการพัฒนาตลอดท้ังโครงการ

อีกดวย เรียกไดวาเปนข้ันตอนของการประเมินงานในทุกสวนเพ่ือใหผูบริหารไดตัดสินใจอยางรอบครอบ

ท่ีสุด

40

2. การออกแบบ เม่ือผานกระบวนการวางแผนมาแลว การออกแบบจึงเปนข้ันตอนท่ีสําคัญ

อีกหนึ่งข้ันตอน อยางไรก็ตามการออกแบบจําเปนตองเรียบงายและครอบคลุมท้ังหมด

3. การเขียนโคด เปนกระบวนการทํางานท่ีละเอียดลออ โปรแกรมเมอรท่ีไดรับมอบหมายนั้น

ควรท่ีจะมีมากกวา 1 คนเพ่ือท่ีจะทําการสลับการตรวจสอบ อีกท้ังหากเกิดปญหาข้ึนจะไดชวยกันแกไขได

4. การทดสอบ เปนข้ันตอนท่ีตรวจสอบการทํางานของระบบ โดยอาจจะทําการทดสอบกันเอง

หรือสงใหลูกคาทดสอบก็เปนไปได ดังภาพท่ี 4.2

ภาพท่ี 4.2 แสดงกระบวนการ เอ็กชทรีม โปรแกรมม่ิง

การพัฒนาซอฟตแวรแบบปรับตัว-เอเอสดี

ถูกคิดคนโดย Jim Highsmith และ Sam Bayer ในป 2000 แบบจําลองนี้เหมาะกับโครงการท่ีมี

ความซับซอนสูง แบงออกเปน 3 ข้ันตอน ดังนี้

1. การคาดเดา (Speculation) ในชวงเริ่มตน จําเปนจะตองมีการกําหนดแผนการทํางาน

2. กําหนดงาน กําหนดเปาหมาย และอ่ืนๆ เทาท่ีจําเปนจะตองมีเพ่ือใหการทํางานนั้นเริ่มตนได

อยางราบรื่น การรวมมือ (Co l l abo ra t ion) ในการทํางานเปนทีมนั้นจําเปนจําตองมีกลุมบุคคลทํา

ดวยกันตองมีความไววางใจกันอีกท้ังยังมีทีมงานท่ีคอยชวยเหลือซ่ึงกันและกัน

3. การเรียนรู (L e a r n i n g) ผูพัฒนาซอฟตแวรมักจะประมาณในสวนของความเขาใจตนเอง

เขาใจความกาวหนาของงานเทคโนโลยีและดานอ่ืนๆ มากเกินจริง ทีมเอเอสดีเรียนรู 3 วิธีคือ 1) กลุม

เฉพาะทาง (Focus Groups) 2) การทบทวนทางเทคนิคอยางเปนทางการ (Formal Technical

Review) 3) การตรวจสอบภายหลัง (Postmortems)

วิธีการประมาณการพัฒนาซอฟตแวร

เปนกิจกรรมหนึ่งท่ีสําคัญของการผลิตซอฟตแวรนอกจากมีกระบวนการท่ีเหมาะสมแลว

การประมาณความยากงายของงานเพ่ือท่ีจะคิดตนทุนท่ีแทจริง ของการพัฒนาซอฟตแวรจึงเปนท่ีตอง

กระทํา

การวางแผน การออกแบบ การเขียนโคด การทดสอบ

41

โคโคโม

โคโคโม (COCOMO model) หรือ COnstruvtive COst MOdel เปนแบบจําลองท่ีใชในการ

ประมาณราคาตนทุนของการพัฒนาซอฟตแวรโคโคโม พัฒนาโดย Berry Boehm ในชวงแรกโคโคโม

นิยมใชกันอยางแพรหลายในการประมาณราคาตนทุนของซอฟตแวร อยางไรก็ตามในเวลาตอมา มีการ

พัฒนา โคโคโม เวอรชัน 2 ข้ึนมาโดยใชแบบจําลอง 3 ชนิดดังตอไปนี้

1. แบบจําลองการพัฒนาซอฟตแวรดวยแนวทางคอมโพเนน มักจะใชในชวงเริ่มตนของการ

พัฒนา ตนแบบของสวนติดตอผูใช การติดตอสื่อสารระหวางระบบและซอฟตแวร ประเมินสมรรถนะของ

ซอฟตแวรประเมินความเหมาะสมของเทคโนโลยีท่ีใช

2. แบบจําลองกอนออกแบบซอฟตแวร เริ่มใชเม่ือความตองการของระบบ ความตองการของ

ผูใช สถาปตยกรรม ซอฟตแวรมีการกําหนดชัดเจน

3. แบบจําลองสถาปตยกรรมหลังการออกแบบ ใชในระหวางข้ันตอนพัฒนาซอฟตแวรและ

หลังจากการออกแบบ

ในแนวทางเดียวกันกับการประมาณราคาตนทุนซอฟตแวร โคโคโม เวอรชัน 2 ใชพิจารณาขนาด

ของขอมูลโดยแบงออกเปน 1) Object Point 2) Function Point และ 3) Line of Source Code

Application-composition Model ของ โคโคโม เวอรชัน 2 ใช Object point นั่นคือ ขนาดของ

ซอฟตแวรจะตองนับเปนอ็อบเจ็กตพอยทเปนการนับจํานวนอ็อบเจ็กตตท่ีหมายถึงคอมโพเนนท 3 สวน

เชน หนาจอ (Screen) รายงาน (Report) และโมดูลท่ีเขียนดวยภาษาโปรแกรมม่ิงในยุค 3GL (Third

Generation Language) ข้ึนไป ระดับความซับซอนของ Object point แบงออกเปน 3 ระดับคือ งาย

ปานกลาง และ ยาก ตามคาน้ําหนัก ดังตารางท่ี 4.1

ตารางท่ี 4.1 ตารางแสดงวิธีการคํานวณ โคโคโม เวอรชัน 2

Simple (งาย) Medium (ปานกลาง) Difficult (ยาก)

Screen 1 2 3

Report 2 5 8

3GL component 10

42

เม่ือคอมโพเนนไดมีการกําหนดตามขนาดน้ําหนักในตาราง การคํานวณ NOP (New Object

Point) สามารถคํานวณจากสมการ

NOP= Object point100%100 reuse−

เม่ือ NOP คือ New Object Point และคอมโพเนน ของซอฟตแวรมีการนํากลับมาใชใหม (Reuse) ใน

การคํานวณคาแรงจากคา NOP นั้น คา PROD (Productivity Rate) นํามาคํานวณโดย

PROD = NOP / man - month หรือ man - month = NOP/PROD

คาแรงท่ีคํานวณไดจะมีคาเปน man-month ซ่ึงคิดจากประสบการณและความสามารถของ

ทีมงาน ดังตารางท่ี 4.2

ตารางท่ี 4.2 ตารางแสดงคาคงท่ีวิธี โคโคโม เวอรชัน 2

ระดับประสบการณ

และความสามารถ

ต่ํามาก

(Very

Low)

ต่ํา

(Low)

ปานกลาง

(Nominal)

สูง

(High)

สูงมาก

(Very High)

PROD 4 7 13 25 50

บทสรุป

ในการพัฒนาซอฟตแวรขนาดใหญนั้น จําเปนจะตองอาศัยบุคลากรหลายฝาย การทํางานรวมกัน

เปนทีมจึงมีความสําคัญอยางยิ่ง ไมเพียงแตจะตองใหความสําคัญเก่ียวกับกระบวนการการทํางานท่ีได

มาตรฐานแลว จําเปนตองคํานึงถึงการใหความสําคัญของการสื่อสารกันของแตละบุคคล การรวมมือกัน

ของทีมงานพัฒนาซอฟตแวร การสื่อสารท่ีเปนลําดับข้ันท่ีเขาใจกันมากกวาเครื่องมือ การใหความสําคัญ

กับซอฟตแวรท่ีผลิตข้ึนมาเพ่ือใชงานไดอยางมีประสิทธิภาพ คูมือการใชงานท่ีอธิบายการทํางานของระบบ

ท่ีอานเขาใจไดงาย ใหความสําคัญตอการปรับตัวในการทํางาน การรวมมือกันแกไขปญหา มากกวาท่ีจะ

เครงครัดกับแผนท่ีตั้งเอาไวโดยไมคํานึงถึงเหตุการณเฉพาะหนา สิ่งเหลานี้คือปจจัยดานบุคคลของอาไจล

ในสวนของเอ็กซทรีม โปรแกรมม่ิง-เอ็กซพี มีสวนชวยใหการทํางานเปนระบบมากยิ่งข้ึน และสิ่งท่ีตอง

พิจารณาคือความยากงายของซอฟตแวรท่ีพัฒนา คือวิธีการประมาณการพัฒนาซอฟตแวร ดวยวิธีโคโคโม

43

เปนวิธีท่ีนิยมกันสําหรับนักวิศวกรซอฟตแวรประมาณความยากงายของการพัฒนาซอฟตแวร ทําให

โครงการบรรลุตามวัตถุประสงคตามเวลาท่ีกําหนด สามารถชวยในการประมาณทรัพยากร และควบคุม

การงานใหตรงตามแผนท่ีกําหนดไวและสงมอบงานใหตรงตามเวลาท่ีกําหนด


1. จงอธิบายเพราะเหตุใดปจจัยดานบุคคลถึงสําคัญกับดานตางๆ ในการพัฒนาซอฟตแวร

2. จงอธิบายการทํางานเปนทีมเม่ืออยูกันคนละแหงควรใชวิธีการทํางานแบบใดจึงสามารถพัฒนา

ซอฟตแวรใหไดประสิทธิภาพมากท่ีสุด

3. จงอธิบายการทํางานในกระบวนการอาไจล วิเคราะหจุดเดนจุดดอยสงผลตอการพัฒนา


4. จงอธิบายจุดเดนจุดดอยสงผลตอการพัฒนาซอฟตแวร เลือกหลักการอาไจล และเทียบดูกับ

แตละแบบจําลองในบทนี้วามีการแสดงออกถึงหลักการนี้อยางไร

5. จงอธิบายเหตุใดความตองการจึงเปลี่ยนแปลงบอย ทําไมผูใชไมทราบความตองการของตนเอง

6. จงอธิบายเพราะเหตุใดกระบวนการทําวนซํ้าจึงงายตอการจัดการความเปลี่ยนแปลง

กระบวนการอาไจลทุกแบบเปนการทําวนซํ้าหรือไม เปนไปไดหรือไมท่ีจะทําโครงการใหเสร็จโดยไมมีการ

ทําวนซํ้าและยังเปนอาไจลอยู อธิบายประกอบคําตอบของคุณ

7. จงอธิบายวิธีการประมาณการพัฒนาซอฟตแวรดวยวิธีโคโคโม

8. จงอธิบายการพัฒนาซอฟตแวรแบบปรับตัว-เอเอสดี

9. จงอธิบายวัตถุประสงคของการนําซอฟตแวรกลับมาใชใหม

10. จงอธิบายวิธีการคํานวน โคโคโม เวอรชัน 2 ในกรณีมีกิจกรรมท่ีนํากลับมาใชใหม คิดเปน

รอยละ 70 ของกิจกรรมท้ังหมด จากตารางท่ีใหมา ดังนี้

ระดับประสบการณ

และความสามารถ

ต่ํามาก

(Very

Low)

ต่ํา

(Low)

ปานกลาง

(Nominal)

สูง

(High)

สูงมาก

(Very High)

PROD 6 9 13 35 50

44

อางอิง






(มหาชน).








what-cmmi.


Engineering", Publication in IJCSI International Journal of Computer

ScienceISSN(Online): 1694-0814, Issues, Vol.7, Issue5, September2010.

Puttasak Tantisuttivet, "Agile and Scrum", คนวันท่ี 19 มกราคม 2559, จาก

https://brandinside.asia/agile-and-scrum-for-new-business/Schwaber, K. (2004).

Agile Project Management with Scrum. Seattle: Microsoft Press.

45

แผนบริหารการสอนประจําบทที่ 5


1. การบริหารโครงการทางดานวิศวกรรมซอฟตแวร

2. การแกปญหาดานวิศวกรรมซอฟตแวร

3. กระบวนการของการบรหิารจัดการซอฟตแวร

4. แผนภูมิแกนท

5. แผนภูมิเพิรท

6. สิ่งท่ีตองคํานึงถึงของการบริหารจัดการโครงการซอฟตแวร

7. ปจจัยสูความสําเร็จในการบริหารโครงการ


1. นักศึกษาสามารถอธิบายการบริหารโครงการทางดานวิศวกรรมซอฟตแวร การแกปญหาดาน

วิศวกรรมซอฟตแวร กระบวนการของการบริหารจัดการซอฟตแวร แผนภูมิแกนท แผนภูมิเพิรท สิ่งท่ีตอง

คํานึงถึงของการบริหารจัดการโครงการซอฟตแวร ปจจัยสูความสําเร็จในการบริหารโครงการได

2. นักศึกษาสามารถอธิบายกระบวนการท่ีทําใหโครงการสําเร็จลุลวงไปไดดวยดีได

3. นักศึกษาสามารถอธิบายการทํางานแผนภูมิแกนทและแผนภูมิเพิรทได



1.1 วิธีการสอนแบบบรรยายเริ่มจาก อธิบายการบริหารโครงการทางดานวิศวกรรม

ซอฟตแวร การแกปญหาดานวิศวกรรมซอฟตแวร กระบวนการของการบริหารจัดการซอฟตแวร แผนภูมิ

แกนท แผนภูมิเพิรท สิ่งท่ีตองคํานึงถึงของการบริการจัดการโครงการซอฟตแวร ปจจัยสูความสําเร็จใน

การบริหารโครงการ

1.2 สามารถอธิบายกระบวนการท่ีทําใหโครงการสําเร็จลุลวงไปไดดวยดี มีการตั้งคําถาม

ตอบคําถามในชั้นเรียนระหวางผูสอนและผูเรียน


46


2.1 แสดงตัวอยางการทํางานแผนภูมิแกนท และแผนภูมิเพิรท

2.2 แบงกลุมอภิปรายเรื่องปจจัยสูความสําเร็จในการบริหารโครงการ










47

บทท่ี 5

การบริหารโครงการซอฟตแวร

ในบทนี้จะกลาวถึงหลักการบริหารโครงการทางดานวิศวกรรมซอฟตแวร โดยมีกิจกรรมท่ีจําเปน

จะตองศึกษา เชน การรวบรวมกิจกรรม การติดตอสื่อสาร การวางแผน การสรางแบบจําลอง การสราง

และการติดตั้ง ซ่ึงท้ังหมดนี้มีความสําคัญมาก อีกท้ังเม่ือเกิดปญหาข้ึนระหวางการพัฒนาซอฟตแวร

ผูบริหารโครงการจะตองรับผิดชอบตอสิ่งท่ีเกิดข้ึน ดังนั้นจึงจําเปนจะตองเรียนรูวิธีการแกปญหาอยางเปน

ระบบ เชน กระบวนการของการบริหารจัดการซอฟตแวรนั้นสามารถชวยลดขอผิดพลาดท่ีอาจจะเกิดข้ึน

ได ในสวนของเครื่องมือท่ีใชในการควบคุมและติดตามงานนั้น เชน แผนภูมิแกนท และแผนภูมิเพิรท

นอกจากนี้ยังมีเครื่องมือการสรางขายปฏิบัติงานเพ่ือใหเห็นภาพรวมของกิจกรรมท้ังโครงการ ผูบริหาร

โครงการและทีมงานควรตองคํานึงถึงการบริหารจัดการโครงการซอฟตแวร เปนสิ่งหนึ่งท่ีชวยกําหนด

ความสําเร็จลุลวงไปได

การบริหารโครงการทางดานวิศวกรรมซอฟตแวร

การบริหารโครงการทางดานวิศวกรรมซอฟตแวรนั้นมีความสําคัญมาก โดยสามารถอธิบาย

ภาพรวมของโครงการ ดังนี้ การรวบรวมกิจกรรม การติดตอสื่อสาร การวางแผน การสรางแบบจําลอง

การสราง และการติดตั้ง ดังภาพท่ี 5.1

ภาพท่ี 5.1 แสดงภาพรวมของการบริหารโครงการ

1. การรวบรวมกิจกรรม การบริหารโครงการจะสําเร็จไดดีนั้นสิ่งท่ีสําคัญคือการกําหนดกิจกรรมท่ี

จะเกิดข้ึนตลอดท้ังโครงการ งานท่ีเก่ียวของในโครงการตั้งแตเริ่มตนโครงการจนกระท่ังสิ้นสุดโครงการ

โดยจะรวบรวมองคความรูท่ีจําเปนตองใชในโครงการ เทคนิคตลอดจนเครื่องมือเพ่ือใหกิจกรรมตางๆ

เหลานั้นบรรลุไปไดตามวัตถุประสงคท่ีไดวางไว

การรวบรวมกิจกรรม การติดตอสื่อสาร การวางแผน

การสรางแบบจําลอง การสราง การติดตั้ง

48

2. การติดตอสื่อสาร เปนกิจกรรมท่ีสรางสรรค และมีความจําเปนอยางมากสําหรับการสื่อสารกัน

ระหวางทีมงานและกับลูกคาท่ีจะตองเขาใจและตัดสินใจรวมกัน การประชุมเพ่ือซักถามหาขอสรุปหรือการ

สื่อสารดวยจดหมายอิเล็กทรอนิกสเพ่ือใหเขาใจตรงกันทุกฝาย

3. การวางแผน การวางแผนเปนหนาท่ีสําคัญอยางยิ่งสําหรับผูบริหารโครงการ หากระหวางการ

ทําโครงงานจริงเกิดปญหาท่ีไมตรงตามแผนการทํางานไปบาง จึงจําเปนตองมีแผนสํารอง และการ

วิเคราะหความเสี่ยงเปนระยะ เพ่ือการสงมอบงานท่ีตรงตามเวลาท่ีกําหนด

4. การสรางแบบจําลอง เปนวิธีท่ีนิยมใชสําหรับการสรางความเชื่อม่ันใหกับลูกคาและเพ่ือใหเห็น

ภาพโครงการท่ีชัดเจนเหมาะสมหรับการบริหารจัดการโครงการ

5. การสราง เปนกิจกรรมท่ีสุมเสี่ยงท่ีจะเกิดขอผิดพลาดได ดังนั้นจึงจําเปนจะตองมีผูท่ีคอย

ควบคุมการทํางานอยางเปนระบบ หากการทํางานเปนทีมไดกระจายงานรวมถึงการติดตามงานอยางเปน

ระบบ เม่ือนํากลับมารวมกันจะทําใหไดงานท่ีมีประสิทธิภาพมากท่ีสุด

6. การติดตั้ง ข้ันตอนท่ีมีความสําคัญตอการทํางานเพราะเปนข้ันตอนท่ีจะทําใหลูกคาพึงพอใจใน

งานท้ังหมดท่ีไดทํามา เม่ือทําการติดตั้งควรใหคําแนะนําการใชงานหลังการติดตั้งตอไปอีกระยะหนึ่ง เพ่ือ

เปนการสรางความอุนใจใหกับลูกคา

การแกปญหาดานวิศวกรรมซอฟตแวร

ในระหวางข้ันตอนการพัฒนาซอฟตแวรนั้นยอมเกิดขอผิดพลาด ติดขัดบางประการโดยท่ีทีมงาน

ไมประสงคใหเกิดข้ึน ดังนั้นจึงมีเทคนิคของการบริหารจัดการซอฟตแวรสาระสําคัญของการแกปญหาดาน

วิศวกรรมซอฟตแวรไวดังนี้

1. การเขาใจถึงปญหาในการพัฒนาซอฟตแวร รวมถึงการสื่อสารและการวิเคราะหระบบงาน คือ

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

การแกปญหาท่ีอาจจะเกิดข้ึนได

2. การวางแผนการแกปญหา ผูบริการโครงการนั้นจําเปนอยางยิ่งท่ีจะตองวางแผนในการ

แกปญหา บางครั้งอาจจะทําการประชุม เพ่ือหาความเสี่ยงท่ีอาจจะเกิดข้ึนสําหรับโครงการและเขียน

แผนการจัดการความเสียงท่ีจะเกิดข้ึนอีกดวย

3. การปฏิบัติตามแผน ผูบริหารโครงการมีหนาท่ีสําคัญคือหม่ันคอยตรวจสอบวางานท่ีไดทําไป

แลวนั้น เปนไปตามแผนงานหรือไม อาจจะมีการประชุมเพ่ือดูความกาวหนาของงานในแตละสัปดาห

49

4. ตรวจดูความถูกตองของผลลัพธ ผูบริการโครงการจะตองใชเครื่องมือในการตรวจสอบคุณภาพ

รวมไปถึงการวัดประสิทธิภาพการใชงาน ความถูกตอง คุมคาของซอฟตแวรท่ีพัฒนา และสรุปผล

กระบวนการของการบริหารจัดการซอฟตแวร

ข้ันตอนของการดําเนินโครงการซอฟตแวร เพ่ือใหกิจกรรมตางๆ เปนไปดวยความราบรื่น โดย

แบงออกเปน 4 ข้ันตอน เชน การวางแผนโครงการ การจัดระเบยีบโครงการ การติดตามสถานะโครงการ

ข้ันตอนการปรับเปลี่ยนโครงการ

ข้ันตอนการวางแผนโครงการ การบริหารโครงการนั้นจะสําเร็จหรือไมสวนหนึ่งข้ึนอยูกับการ

วางแผนโครงการท่ีดี รวมไปถึงการวางแผนท่ีจะรับมือกับปญหาท่ีจะเกิดข้ึนอีกดวย สิ่งท่ีตองวางแผนมี

ดังตอไปนี้

1. แผนงานคุณภาพ คือแผนงานท่ีแสดงใหเห็นวาตลอดการทํางานนั้นไดมีมาตรฐานวางแผน

เก่ียวกับคุณภาพ ท่ีตองการเม่ือสงมอบงาน

2. แผนงานการทวนสอบ แสดงใหเห็นวามีการทวนสอบอยูเปนระยะ และตลอดระยะเวลาของ

โครงการมีการปรับปรุงไปแลว สวนใดบาง เพ่ือเปนประโยชนตอการทํางาน

3. แผนการบํารุงรักษาระบบ เปนแผนท่ีบอกถึงภายหลังจากการสงมอบระบบนั้นแลว โดยให

ขอมูลเก่ียวกับวิธีดําเนินการบํารุงรักษาระบบ วาควรทําอยางไรเพ่ือใหสามารถใชงานระบบไดอยางคงทน

4. การประมาณการ หมายถึงการประมาณทรัพยากรท่ีใชในการทําโครงการพัฒนาซอฟตแวร

โดยประมาณการเปนหนวยวัด ตามความเหมาะสม

ข้ันตอนการจัดระเบียบโครงการ จะเริ่มตนเม่ือข้ันตอนการวางแผนโครงการไดสิ้นสุดลง โดยได

เริ่มทําการจัดระเบียบโครงสรางองคกร การจัดจางทรัพยากรบุคคล และการจัดหาทรัพยากรท่ีจําเปนตอง

ใชในโครงการ ผูบริหารโครงการบางทานท่ีมีทัศนวิสัยกวางไกลอาจจะทําการหาหลักสูตรอบรมใหกับทีม

พัฒนาซอฟตแวร เพ่ือใหไดองคความรูใหม เหมาะสมและปรับใชกับองคกรไดอยางมีประสิทธิภาพ

ข้ันตอนของการติดตามสถานะโครงการ เปนการติดตามความกาวหนาของงานและสถานะท่ีจะ

สงผลใหการสงมอบงานนั้นลาชาออกไป เปนการปองกันความผิดพลาดท่ีจะเกิดข้ึนอีกทางหนึ่ง ในสวนของ

50

การติดตามโครงการเปนหนาท่ีสําคัญของผูบริหารโครงการท่ีตองคอยหม่ันตรวจสอบถึงความถูกตองของ

งาน ความลาชาอาจจะสงผลทําใหเกิดความเสียหายตอการสงมอบโครงการก็เปนได เครื่องมือท่ีใชในการ

จัดตารางงานเพ่ืองายแกการติดตามตรวจสอบท่ีสําคัญ เชน แผนภูมิแกนท

ข้ันตอนการปรับเปลี่ยนโครงการ หลังจากท่ีโครงการไดดําเนินไประยะหนึ่งแลวนั้น ในบางครั้ง

พบวามีความจําเปนตองเปลี่ยนแปลงขอบเขตของงาน สาเหตุอาจจะเกิดจากความผิดพลาดท่ีเกิดข้ึนนั้น

สงผลใหตองมีการเปลี่ยนแปลง ไมวาจะเปนในดานของการลงทุน การบริหารจัดการทรัพยากร ฯลฯ ท้ังนี้

เพ่ือใหสามารถสงมอบซอฟตแวรไดทันกับเวลาท่ีกําหนด

แผนภูมิแกนท

แผนภูมิแกนท (Gantt chart) คือแผนภูมิแทงเปนแผนภูมิท่ีใชเปนเครื่องมือควบคุมโครงการ

แสดงเวลาเริ่มตน-สิ้นสุดของกิจกรรมตางๆ ท่ีไดกําหนดไวในโครงการ ออกแบบโดย Henry L. Gantt

(1861–1919) ลักษณะของแผนภูมิแกนทจะเปนการแสดงความสัมพันธระหวางกิจกรรมตางๆ ใน

โครงการ เวลาของการปฏิบัติงานของแตละกิจกรรม นอกจากนี้ยังสามารถตรวจสอบสถานะปจจุบันของ

โครงการเปรียบเทียบกับแผนงานของโครงการดวยเพ่ือใชในการตรวจสอบและติดตามความกาวหนาของ

โครงการ โดยท่ัวไปแผนภูมิแกนทนิยมใชในการโครงการขนาดเล็ก ไมซับซอน เนื่องจากเปนแผนภูมิท่ีงาย

ในการสรางและงายตอการตอการทําความเขาใจทําใหเขาใจภาพรวมของระบบไดงายข้ึน และยังเปน

เครื่องมือท่ีใชประโยชนในการวางแผนและแสดงตารางเวลาของโครงการ เปนเครื่องมือท่ีชวยติดตามความ

คืบหนาของโครงการ อยางไรก็ตามแผนภูมิแกนทไมสามารถบอกไดวาถากิจกรรมท่ีเกิดข้ึนกอนหนาเกิด

ความลาชา แลวจะมีผลกระทบกับกิจกรรมท่ีเกิดข้ึนทีหลังอยางไร

วิธีการสรางแผนภูมิแกนท

ในการสรางแผนภูมิแกนทนั้นจะทําใหสามารถมองเห็นภาพรวมของโครงการท้ังหมดได ดังจะมี

ข้ันตอนดังตอไปนี้ ดังภาพท่ี 5.2

1. ศึกษาและทําความเขาใจโครงการโดยละเอียด

2. แจกแจงรายละเอียดกิจกรรมของแผนงานโดยละเอียด โดยเริ่มตั้งแตกําหนดวันเริ่มตนของ

แตละงานหรือกิจกรรม ประมาณการระยะเวลาของแตละกิจกรรม มีกิจกรรมใดบางท่ีตองดําเนินพรอมกัน

หรือมีกิจกรรมใดบางท่ีตองมีลําดับกอนหลัง ถามีตองระบุบความสัมพันธดวย

51

3. จัดทําแผนภูมิแกนท โดยแกนนอนจะแทนระยะเวลา สวนแกนตั้งจะแทนกิจกรรม

ภาพท่ี 5.2 แสดงภาพตัวอยางแผนภูมิแกนท

ขอจํากัดของการใชแผนภูมิแกนท

สําหรับการใชแผนภูมิแกนทนั้นมีขอจํากัดบางประการ ดังจะอธิบายดังนี้

1. แผนภูมิแทงหรือแผนภูมิแกนทไมสามารถแสดงความสัมพันธระหวางกิจกรรมตางๆ ได

เนื่องจากแผนภูมิแทงเปนการแสดงความสัมพันธระหวางกิจกรรมหนึ่งกับเวลาท่ีใชหรือเวลาท่ีจะทํา

กิจกรรมนั้น แตไมแสดงความสัมพันธกับกิจกรรมอ่ืนๆ ท่ีจะเก่ียวของดวย ซ่ึงอาจทําใหเกิดผลกระทบใน

การดําเนินโครงการท่ีตองดําเนินกิจกรรมแตละกิจกรรมใหสัมพันธกัน

2. แผนภูมิแทงหรือแผนภูมิแกนท ไมแสดงใหเห็นวามีกิจกรรมใดบางท่ีสามารถยอมใหดําเนินการ

ชาไดโดยไมมีผลกระทบตอกิจกรรมอ่ืนในการดําเนินโครงการ

3. แผนภูมิแทงหรือแผนภูมิแกนทไมบงบอกใหเห็นวากิจกรรมยอยใดเปนกิจกรรมวิกฤติซ่ึง

หมายถึง กิจกรรมท่ีสงผลกระทบตอกิจกรรมอ่ืนๆ ถากิจกรรมนั้นลาชาจะทําใหเวลาท้ังหมดของโครงการ

ชากวากําหนดไปดวย

4. แผนภูมิแทงหรือแผนภูมิแกนทไมสะดวกในการปรับแกหรือปรับปรุง ถามีการเปลี่ยนแปลง

กิจกรรมในโครงการยอย

5. แผนภูมิแทงหรือแผนภูมิแกนทไมเหมาะสมกับโครงการท่ีมีกิจกรรมมากๆ อาจจะทําใหเกิด

ความสับสนในการอานแผนภูมิ

52

แผนภูมิเพิรท

แผนภูมิเพิรท (Program evaluation and review technique : PERT) เป นเทคนิควิธีการ

วางแผนและการควบคุมแผนซ่ึงมีความซับซอน โดยแสดงถึงขายของงาน ท่ีประกอบดวยเหตุการณและ

กิจกรรม กับเวลาโดยประมาณ เพ่ือคํานวณหาเวลาท่ีคาดหวังของกิจกรรมแตละกิจกรรมจะแลวเสร็จ

(ประชุม, 2547) PERT chart แสดงแตละกิจกรรมในโครงการเปนโหนด (Node) ความสัมพันธกันของแต

ละกิจกรรม เวลาของแตละกิจกรรม

ประโยชนของแผนภูมิเพิรท

ความสําคัญของการหาเสนทางท่ีสําคัญนั้น เหตุผลสวนหนึ่งเพ่ือเปนการประมาณงานท่ีใชเวลาใน

กิจกรรมใดกิจกรรมหนึ่งมาก หรือนอยจนเกินไป ดังนั้นแผนภูมิเพิรทจึงสามารถแสดงใหเห็นไดวาควร

จะตองคํานึงถึงในกิจกรรมท่ีใชเวลามากจนเกินไป

1. สามารถกําหนดกิจกรรมท่ีสําคัญท่ีสุดสําหรับเสนทางท่ีสําคัญ (Critical Path) เนื่องจาก

เสนทางดังกลาวนําไปสูระยะเวลาข้ันต่ําท่ีโครงการตองการความลาชาในงานเหลานี้ จะสงผลใหเกิดความ

ลาชาตอโครงการโดยรวม

2. สามารถกําหนดไดวาตองลดเวลาของกิจกรรมใดในโครงการเพ่ือลดเวลาโดยรวมของ

โครงการ

3. กําหนดไดวากิจกรรมใดๆ ในโครงการสามารถดําเนินงานพรอมๆ กันได

4. สามารถกําหนดกิจกรรมใดๆ ท่ีไมมีผลกระทบตอความลาชาของโครงการโดยรวม

การหาคาเวลาของกิจกรรม

PERT ใชในการประมาณการเวลาของกิจกรรมตางๆ โดยการพิจารณาคาเวลาท้ัง 3 คาคือ

1. คาเวลาท่ีเร็วท่ีสุดท่ีสามารถดําเนินกิจกรรมใหแลวเสร็จ (O หรือ Optimistic Time)

2. คาเวลาท่ีนาจะทําไดเสร็จในสภาวะปกติ (M หรือ Most Likely Time)

3. คาเวลาท่ีชาท่ีสุดในการปฏิบัติกิจกรรมนานท่ีสุด (P หรือ Pessimistic Time) การคํานวณ

เวลาท่ีคาดหมายวาจะทํากิจกรรมเสร็จ (E หรือ Expect Time), tE

64 PMOtE

++=

53

ตารางท่ี 5.1 ตารางแสดงตัวอยางการคํานวณคาเวลาของกิจกรรม

ID Task Name

Pred

eces

sor

Task

(s)

Opt

imist

ic T

ime

(O)

Mos

t Li

kely

Tim

e

(M)

Pess

imist

ic T

ime

(P)

Expe

cted

Tim

e (T

E)

1 รวบรวมขอมูลและความตองการของลูกคา 1 2 3 2.00

2 ออกแบบหนาจอโตตอบ 1 3 4 5 4.00

3 ออกแบบฐานขอมูล 1 2 3 4 3.00

4 เขียนโปรแกรม 2, 3 5 6 7 6.00

5 ทดสอบโปรแกรม 4 1 2 3 2.00

6 แกไขโปรแกรม 5 3 4 5 4.00

7 อบรมโปรแกรมใหกับผูเก่ียวของ 6 0 1 2 1.00

8 ติดตั้งโปรแกรมและใชงานจริง 7 0 1 2 1.00

การสรางขายปฏิบัติงาน

ขายปฏิบัติงานสรางข้ึนจากกิจกรรมตางๆ ในโครงการรวมถึงความสัมพันธของแตละกิจกรรม โดย

ปกติการสรางเครือขายปฏิบัติงานของ PERT มีองคประกอบท่ีสําคัญดังนี้คือ

เหตุการณ (Events) หรือฐานกิจกรรม (Node) หมายถึงจุดเริ่มตนหรือสิ้นสุดของแตละกิจกรรม

ซ่ึงจะไมใชเวลาหรือทรัพยากรใดๆ โดยปกติจะแทนดวยวงกลม (O)

กิจกรรม (Activity) หมายถึง งานตางๆ ในโครงการท่ีตองทําใหบรรลุในชวงเวลาหนึ่ง โดย

กิจกรรมจะมีเหตุการณท่ีเปนจุดเริ่มตนและเหตุการณท่ีเปนจุดสิ้นสุดโดยใชลูกศร ( ) เปนตัวเชื่อม

กิจกรรมระหวางเหตุการณเริ่มตนและเหตุการณสิ้นสุด

กิจกรรมหุน (Dummy activity) หมายถึงกิจกรรมท่ีกําหนดข้ึนเพ่ือแสดงความเชื่อมโยงกิจกรรม

ท่ีไมตองใชเวลาและทรัพยากร โดยใชลูกศรเสนประ ( ) เปนตัวเชื่อมกิจกรรม

การหาเวลาท้ังหมดของโครงการหาไดโดย การนําเวลาท่ีใชในแตละกิจกรรมตามสายปฏิบัติการ

มาแตละเสนทางมารวมกัน แลวนํามาเปรยีบเทียบวาเสนทางท่ีรวมแลวใชเวลามากท่ีสุดจะเปนเวลา

ท้ังหมดของโครงการและถือวาเปนเวลาท่ีนอยท่ีสุดท่ีจะทําโครงการนั้นใหสําเร็จได

54

ภาพท่ี 5.3 แสดงกราฟวิธีการ PERT

ตัวอยางโดยดูจากขายงานจากภาพ

เสนทางท่ี 1 คือเวลาท่ีใชในกิจกรรม 1+2+4+5+6+7+8

เสนทางท่ี 2 คือเวลาท่ีใชในกิจกรรม 1+3+4+5+6+7+8

จากตัวอยางนี้เวลาท่ีใชในแตละเสนทางเปนดังนี้

เสนทางท่ี 1 คือ 2+4+6+2+4+1 = 19 สัปดาห

เสนทางท่ี 2 คือ 2+3+6+2+4+1 = 18 สัปดาห

สรุป เวลาท่ีใชนอยท่ีสุดท่ีสามารถดําเนินโครงการใหบรรลุจุดมุงหมาย คือ 19 สปัดาห

สิ่งที่ตองคํานึงถึงของการบริหารจัดการโครงการซอฟตแวร

การบริหารจัดการโครงการซอฟตแวรมีความยากงายแตกตางกันไป ข้ึนอยูกับความซับซอนของ

โครงการ รวมถึงการบริหารจัดการโครงการ สิ่งท่ีตองคํานึงถึงในการบริหารจัดการซอฟตแวรมีดังนี้

1. ซอฟตแวรเปนผลิตภัณฑท่ีไมสามารถจับตองได ถึงแมวานิยามอาจจะไมชัดเจนแตเม่ือ

เทียบกับโครงงานท่ีผลิตชิ้นสวนทางอิเล็กทรอนิกสนั้นสามารถจับตองและใชงานไดจริงแตซอฟตแวรนั้นให

ความหมายการใชงานท่ีตางไป ดังนี้ ขอควรคํานึงถึงจึงเปนความตองการของผูใชงานสามารถใชงานไดจริง

ใชงานงายไมสับสน หรือแมแตการออกแบบมาเพ่ือสองตอบตอผูใชงานเฉพาะกลุมอีกดวย

55

2. กระบวนการผลิตซอฟตแวรไมมีมาตรฐานท่ีแนนอน ถึงแมวาปจจุบันจะมีหนวยงานท่ี

พยายาม จัดทํามาตรฐานการพัฒนาซอฟตแวร เพ่ือใหใชไดครอบคลุม แตดวยความหลากหลายนี้เองทําให

ไมสามารถท่ีจะยึดเอามาตรฐานใดเพียงอยางเดียวมาวัดได ดังนั้นข้ันตอนการพัฒนาซอฟตแวรจึงทําได

เพียงควบคุมการทํางานใหสอดคลองกันไป

ปจจัยสูความสําเร็จในการบริหารโครงการ

สถาบันพีเอ็มไอ (Project Management Institute: PMI) ไดกําหนดกรอบปจจัยท่ีจะนําไปสู

ความสําเร็จในการบรหิารโครงการไว 9 สวนดังนี้

1. การบริหารโครงการโดยรวม คือ ตองม่ันใจวาการบริหารงานกับทุกฝายนั้นเปนไปดวยดี

ผูบริหารโครงการมีหนาท่ีสําคัญท่ีจะตองดูแลภาพรวมใหเปนไปโดยราบรื่น

2. การบริหารขอบเขตโครงการ เปนการบริหารงานเพ่ือใหอยูในขอบเขตท่ีกําหนดไว เปนการ

ทบทวนสิ่งใดควรทําหรือไมควรทําไปดวยอีกทางหนึ่ง สิ่งท่ีผูบริหารโครงการควรจะตองทําคือการกําหนด

โครงสรางของงานในแตละระยะของงานเพ่ือใชประกอบการตัดสินใจท่ีจะทํางานนั้นตอไปหรือไม

3. การบริหารเวลาโครงการ ผูบริหารโครงการจําเปนตองสงมอบงานใหตรงเวลา ดังนั้นการ

บริหารเรื่องของเวลาจึงมีความจําเปนอยางยิ่ง การกําหนดเวลาของกิจกรรมท่ีทําและวิเคราะหความลาชา

ท่ีอาจจะเกิดข้ึนเปนสิ่งท่ีชวยใหบริหารจัดการเวลาไดดีข้ึน

4. การบริหารตนทุนโครงการ การไดรับเงินงบประมาณนั้นเปนสิ่งท่ีตองคํานึงถึงในการบริหาร

จัดการเรื่องตนทุนโครงการ ผูบริหารโครงการตองประมาณการใชงานประมาณ เพ่ือควบคุมการ

เปลี่ยนแปลงของตนทุนท่ีอาจจะเกิดข้ึน

5. การบริหารคุณภาพโครงการ เปนการบริหารเพ่ือใหทุกกิจกรรมในโครงการมีคุณภาพตามท่ีได

กําหนดไว ผูบริหารโครงการตองจัดทําระบบประกันคุณภาพ เพ่ือใหเกิดความชัดเจน และเชื่อม่ันจาก

ลูกคา

6. การบริหารทรัพยากรบุคคลของโครงการ เปนการบริหารงานเพ่ือใหการใชทรัพยากรบุคคลให

ไดประโยชนอยางคุมคามากท่ีสุด ผูบริหารจําเปนตองกําหนดหนาท่ี บทบาท และสายการบังคับบัญชาท่ี

ชัดเจน จึงจะสงผลใหการทํางานเปนประสิทธิภาพมากท่ีสุด

7. การบริหารการสื่อสารในโครงการ เปนหนาท่ีของทีมพัฒนาซอฟตแวรและผูบริหารโครงการ

ท่ีจะตองหาวิธีการสื่อสารกันใหถูกตองแมนยําและเหมาะสม อีกท้ังยังตองสื่อสารกันกับบุคคลภายนอก

เพ่ือใหประสานงานในเรื่องตางๆ บรรลุไดดวยดี

56

8. การบริหารความเสี่ยงของโครงการ หลักสําคัญของการบริหารความเสี่ยงคือการวิเคราะห

ความเสี่ยงท่ีอาจจะเกิดข้ึน และหาแนวทางในการปองกันความเสี่ยงนั้น หากไมสามารถท่ีจะปองกันไดใหผู

บริการโครงการเขียนแผนการการจัดการความเสี่ยงข้ึนเพ่ือใชเม่ือจําเปนอีกดวย

9. การบริหารจัดซ้ือของโครงการ เปนการบริหารการจัดซ้ือจัดจาง เปนหนึ่งในกระบวนการ

จัดหาทรัพยากรท่ีมีความจําเปนตองใชในโครงการ ผูบริหารโครงการควรพิจารณาถึงความจําเปนเปน

ลําดับแรก รวมถึงความคุมคาของการใชงานอีกดวย

บทสรุป

การบริหารจัดการโครงการทางดานวิศวกรรมซอฟตแวรนั้น ไมเพียงแตเปนหนาท่ีของผูบริหาร

โครงการเพียงฝายเดียว ทีมงานพัฒนาซอฟตแวรเปนสวนสําคัญทําใหโครงการสําเร็จลุลวงดวยดีเชนกัน

หากไมสามารถหลีกเลี่ยงจากปญหาท่ีเกิดข้ึนได จําเปนจะตองมีวิธีในการแกปญหาท่ีอาจจะเกิดข้ึน โดย

อาศัยกระบวนการของการบริหารจัดการดานซอฟตแวรดวยเครื่องมือท่ีชวยในการควบคุมกิจกรรมและ

กระบวนการท่ีเกิดข้ึน เชน แผนภูมิแกนท และ เพิรท ซ่ึงการใชแผนภูมิเพิรท กรณีท่ีแผนงานโครงการมี

ความซับซอนสูง อาจจะเนื่องมาจากความซับซอนของการหาคาเวลาท่ีใชในแตละกิจกรรม สามารถ

คํานวณไดละเอียดกวา ท้ังสองสามารถท่ีจะติดตามข้ันตอนการทํางานไดตลอดท้ังโครงการ อีกท้ังการ

วางแผนงานท่ีดีตั้งแตเริ่มโครงการมีสวนชวยอยางมากท่ีจะทําใหโครงการประสบความสําเร็จ เพ่ือใหทันตอ

การสงมอบ เครื่องมือท้ังสองสามารถนํามาวิเคราะหเนื้อหากิจกรรมของโครงการท่ีอาจจะทําใหโครงการ

เกิดความลาชาได อยางไรก็ตามทักษะดานการบริหารโครงการก็เปนสิ่งท่ีสําคัญ เชน ทักษะของการสื่อสาร

กันในทีมงาน ท่ีสามารถสรางความเขาใจท่ีตรงกันไดทุกฝาย ปจจัยท่ีสําคัญในการบริหารโครงการ เชน

การบริหารตนทุนโครงการ จําเปนตองมีการวิเคราะหความเสี่ยงในทุกกระบวนการท่ีอาจจะเกิดความ

ผิดพลาดสงผลกระทบตอโครงการได


1. จงอธิบายปจจัยท่ีนําไปสูความสําเร็จของการบริหารจัดการโครงการขนาดใหญ

2. จงอธิบายภาพรวมของการบริหารจัดการโครงการ

3. จงอธิบายกระบวนการบริหารจัดการโครงการ

4. จงอธิบายความสําคัญของการติดตามความกาวหนาของโครงการ

5. จงอธิบายจุดเดนของการใชแผนภูมิแกนท

57

6. จงอธิบายจุดเดนของการใชแผนภูมิเพิรท

7. จงอธิบายความลาชาของกิจกรรมท่ีเกิดข้ึนในการพัฒนาซอฟตแวร จะสงผลกระทบอยางไร

ตอผูพัฒนาซอฟตแวร

8. จงอธิบายสิ่งท่ีตองคํานึงถึงของการบริหารจัดการโครงการซอฟตแวร

9. จงอธิบายกระบวนการผลิตซอฟตแวรท่ีไมไดมาตรฐาน จะสงผลเสียตอผูพัฒนาซอฟตแวร

อยางไรบาง

10. จงอธิบายปจจัยสูความสําเร็จในการบริหารโครงการ

58

อางอิง



ครรชิต มาลัยวงศ, "การบริหารโครงการซอฟตแวรและC M M " , สํานักงานพัฒนาวิทยาศาสตรและ

เทคโนลยีแหงชาติ, วันท่ี 11 กุมภาพันธ 2543. คนวันท่ี 20 มกราคม 2559, จาก

http://www.drkanchit.com/presentations/cmm.pdf




(มหาชน).








what-cmmi.





https://brandinside.asia/agile-and-scrum-for-new-business/ Schwaber, K. (2004).


Ian Sommerville, (2010). "Software Engineering(9th Edition)", Addison-Wesley Publishing

Company.

https://brandinside.asia/agile-and-scrum-for-new-business/

59



1. การออกแบบเชิงสถาปตยกรรม

2. การจัดโครงสรางของซอฟตแวร

3. การแบงสวนควบคุมการทํางานของซอฟตแวร

4. ระบบประมวลผลของซอฟตแวร


1. นักศึกษาสามารถอธิบายความหมาย การออกแบบเชิงสถาปตยกรรม การจัดโครงสรางของ

ซอฟตแวร การแบงสวนควบคุมการทํางานของซอฟตแวรได

2. นักศึกษาสามารถออกแบบระบบประมวลผลของซอฟตแวรได

3. นักศึกษาสามารถอธิบายจุดเดน จุดดอยของวิธีการออกแบบซอฟตแวรแบบตางๆ ได



1.1 วิธีการสอนแบบบรรยาย เริ่มจากอธิบายการออกแบบเชิงสถาปตยกรรม การจัด

โครงสรางของซอฟตแวร การแบงสวนควบคุมการทํางานของซอฟตแวร ระบบประมวลผลของ





2.1 แสดงตัวอยางการทํางานโครงสรางแบงปนการบริการลูกขายและแมขาย

2.2 แบงกลุมอภิปรายเรื่องจุดเดนจุดดอยของการจัดโครงสรางของซอฟตแวรแบบตางๆ






60





61

บทท่ี 6

การจัดการโครงสรางซอฟตแวรเชิงสถาปตยกรรม

ในบทนี้จะกลาวถึงการจัดการโครงสรางซอฟตแวรเชิงสถาปตยกรรม การออกแบบจําลองสวนท่ี

สําคัญ เชน แบบจําลองสวนประสาน แบบจําลองเชิงโครงสราง แบบจําลองไดนามิก แบบจําลองแสดง

ความสัมพันธ และแบบจําลองแสดงการกระจาย เปนตน การจัดการโครงสรางซอฟตแวรมีความสําคัญ

เปนอยางมาก การเลือกใชโครงสรางแบบตางๆ ใหเหมาะสมจะทําใหซอฟตแวรมีประสิทธิภาพมากยิ่งข้ึน

นอกจากนี้การแบงสวนควบคุมการทํางานของซอฟตแวรจะทําใหสามารถเขียนโปรแกรมไดงายยิ่งข้ึน การ

จัดการโครงสรางของซอฟตแวรมีความสัมพันธกับการประมวลผลของซอฟตแวร เชน ระบบการ

ประมวลผลขอมูล ระบบประมวลผลรายการขอมูล ระบบประมวลผลตามเหตุการณ ท้ังหมดท่ีกลาวมานี้

จําเปนตองพิจารณาเลือกใหเหมาะสมกับซอฟตแวรท่ีพัฒนา

การออกแบบเชิงสถาปตยกรรม

คือการกําหนดโครงสรางของซอฟตแวรในมุมมองระดับบน เปรียบเสมือนสถาปนิกท่ีออกแบบ

บานเพ่ือใหเห็นฟงกชันการใชงานท้ังหมดของบาน ซอฟตแวรก็เชนเดียวกัน นักวิศวกรซอฟตแวรจะมี

หนาท่ีในการออกแบบสวนของฟงกชันการใชงานเพ่ือนตอบสนองการใชงานจริง แบบจําลองเชิง

สถาปตยกรรมนั้นจะเสนอมุมมองในแตละดาน ดังตอไปนี้

แบบจําลองสวนประสาน (Interface Model) แสดงใหเห็นภาพรวมการทํางานทุกสวนภายใน

ระบบผานการใหบริการ มุมมองของผูใชงาน

แบบจําลองเชิงโครงสราง (Static Structural Model) เปนสวนท่ีแสดงใหเห็นถึงสวนประกอบ

ยอย เรียกอีกอยางวา คอมโพเนนทแตละสวนของซอฟตแวร

แบบจําลองไดนามิก (Dynamic Model) แสดงสวนทีมีการตอบสนอง หรือมีการเปลี่ยนแปลง

จากการทํางานของระบบ

แบบจําลองแสดงความสัมพันธ (Relationship Model) เปนการแสดงความสัมพันธระหวาง

ระบบยอยเพ่ือสื่อใหเขาใจตรงกันของระบบ เชน DFD (Data Flow Diagram)

แบบจําลองแสดงการกระจาย (Distributed Model) แสดงใหเห็นการกระจายสวนประกอบยอย

ของการทํางานแตละสวน

การจัดโครงสรางของซอฟตแวร

เรียกอีกอยางวา การจัดโครงสรางของระบบ นักออกแบบระบบจํานวนมากใหความสําคัญกับการ

ออกแบบโครงสรางซอฟตแวรเนื่องจากสงผลตอคุณภาพและการใชงานของซอฟตแวร รูปแบบโครงสราง

62

ซอฟตแวรโดยท่ัวไปแบงเปน 3 แบบ ดังนี้ โครงสรางแบบแบงปนแหลงเก็บขอมูล โครงสรางแบบแบล็ค

บอรด โครงสรางแบบแบงปนการบรกิารลูกขายและแมขาย

โครงสรางแบบแบงปนแหลงเก็บขอมูล

เปนโครงสรางท่ีมีคุณลักษณะเดนของการนําระบบยอยมารวมกัน เพ่ือใหเกิดซอฟตแวรข้ึนมา

ดังนั้นโครงสรางนี้จึงเนนสวนของการแบงปนขอมูลระหวางกัน จําเปนท่ีจะตองมีความถูกตองท่ีสุด วิธีการ

การแบงปนขอมูลกันมีดังตอไปนี้

1. การจัดเก็บขอมูลโดยฐานขอมูลเดียวกัน เพ่ือความสะดวกในการใชขอมูลรวมกัน ทุกระบบ

ยอยสามารถใชขอมูลเดียวกันไดอยางถูกตอง เรียกแบบนี้วา เร็บพรอซิทอรี โมเดล (Repository Model)

2. แตละระบบยอยมีการสื่อสารดวยการสงขอความถึงกัน เมสเซจ (Massage) การทํางาน ของ

โครงสรางนี้จึงนําไปสงอีกหลายระบบท่ีเกิดข้ึนมาเพ่ือรองรับการทํางานท่ีเหมาะสม เชน ระบบบริหาร

จัดการสารสนเทศ (Management Information System)

โครงสรางแบบแบล็คบอรด

เปนอีกรูปแบบหนึ่งของการแบงปนขอมูลกันในการพัฒนาระบบยอยรวมกัน ขอจํากัดเฉพาะคือ

เหมาะสําหรับระบบท่ีไมมีโครงสราง หรือมีลักษณะของขอมูลท่ีไมแนนอน และเม่ือมีการเปลี่ยนแปลงของ

ขอมูลจะมีตัวดําเนินการเรียกวา ทริกซเกอร (Trigger) เปนตัวกระตุนการทํางานของระบบยอย

องคประกอบท่ีสําคัญ 3 สวนของโครงสรางนี้ เชน 1) แบล็คบอรด (Blackboard) 2) แหลงความรู

(Knowledge Source) 3) ตัวควบคุม (Control)

สําหรับนักวิศวกรซอฟตแวร การดําเนินการออกแบบโครงสรางแบบแบล็กบอรด ควรพิจารณาถึง

จุดเดนและจุดดอย เพ่ือเลือกใชใหเหมาะสมตอไป ดังตารางท่ี 6.1

ตารางท่ี 6.1 ตารางแสดงจุดเดนจุดดอยของโครงสรางแบบแบล็คบอรด

จุดเดน ของโครงสรางแบบแบล็คบอรด จุดดอย ของโครงสรางแบบแบล็คบอรด

เปนวิธีท่ีเหมาะสมสําหรับการมีขอมูลขนาด

ใหญ ขามการสงผานขอมูลเหลานั้นใหกับระบบ

ยอย เพ่ือลดเวลาการทํางานลง เปนเครื่องมือท่ี

สําคัญสําหรับการสํารองขอมูลท่ีดี รวมถึงการ

รักษาความปลอดภัย การควบคุมการกําหนดสิทธ ิ

ขอจํากัดบางประการของระบบยอยท่ี

จําเปนจะตองมีสถาปตยกรรมเดียวกันจึงจะทําให

ใชงานไดเต็มประสิทธภาพบางครั้งพบวาระบบ

ยอยอ่ืนใชแบบจําลองตางออกไปอาจจะทําให

ระบบไมสามารถทํางานรวมกันไดการกระจาย

63

จุดเดน ของโครงสรางแบบแบล็คบอรด จุดดอย ของโครงสรางแบบแบล็คบอรด

ในการใชขอมูลเหลานั้น อีกดวยสามารถนํา

เครื่องมือ หรือซอฟตแวรควบคุมตัวอ่ืนเขามาใช

งานรวมกันได การเพ่ิมหรือลดฟงกชันการใชงาน

สามารถทําไดตามความเหมาะสม

ขอมูล ระหวางระบบยอยนั้นบางครั้งพบวามี

ความซํ้าซอนของขอมูลเกิดข้ึนบางทําใหจําเปนท่ี

จะตองมีระบบตรวจสอบความซํ้าซอนของขอมูล

และทําการลบขอมูลดังกลาวออกไปเพ่ือปองกัน

ความผิดพลาด

โครงสรางแบบแบงปนการบริการลูกขายและแมขาย

เปนโครงสรางท่ีมีความนิยมสูงท่ีสุดในปจจุบัน โดยมีการบริหารจัดการแบบการรองขอบริการและ

ใหบริการ ดังนั้นองคประกอบหลักของโครงสรางนี้เชน เครื่องลูกขาย เครื่องแมขายและระบบเครือขาย

1. เครื่องแมขาย (Server) เปนเครื่องคอมพิวเตอรท่ีมีประสิทธิภาพสูงทําหนาท่ีใหบริการแก

เครื่องคอมพิวเตอรลูกขาย ในสวนของซอฟตแวรบริหารจัดการเครื่องแมขายนั้นจําเปนจะตองมีฟงกชัน

สําหรับการใหบริการท่ีมีประสิทธิภาพอีกดวย

2. เครื่องลูกขาย (Client) เปนเครื่องคอมพิวเตอรท่ีเรียกใชบริการเครื่องแมขาย โดยการทํางาน

จะเกิดข้ึนบนเครืองลูกขาย และโปรแกรมตางๆ สามารถทํางานบนเครื่องแมขายไดเม่ือมีการเรียกใช

บริการจากเครื่องแมขาย

3. ระบบเครือขาย (Network) เปนสวนท่ีจําเปนสําหรับโครงสรางนี้มีหนาท่ีเชื่อมตอกันระหวาง

เครื่องคอมพิวเตอรแมขาย ฝงของการใหบริการ และเครื่อคอมพิวเตอรลูกขาย สําหรับการขอรับบริการ

การเชื่อมตอดวยระบบเครือขายนี้ทําไดหลายรูปแบบ ข้ึนอยูกับความพรอมและสถาปตยกรรมภายในของ

ระบบ สิ่งท่ีสําคัญคือตองสามารถเชื่อมตอระหวางเครื่องท้ังสองไดอยางมีประสิทธิภาพ

ตัวอยางระบบเครือขายแสดงการทํางานของระบบใหบริการเก็บภาพถาย วีดีโอ ผานทางเว็บ

บราวเซอร แบบมีผูใชบริการพรอมกันหลายยูสเซอร ท้ังหมดนี้เรียกใชบริการผานเครือขายอินเทอรเน็ต

ดังภาพท่ี 6.1

64

ภาพท่ี 6.1 แสดงโครงสรางแบบแบงปนการบริการลูกขายและแมขาย

ท่ีมา: http://www.mhhe.com/engcs

สําหรับนักวิศวกรซอฟตแวรการออกแบบโครงสรางแบบแบงปนการบริการลูกขายและแมขายนั้น

ควรพิจารณาจุดเดนจุดดอย เพ่ือเลือกใชใหเหมาะสมตอไป ดังตารางท่ี 6.2

ตารางท่ี 6.2 จุดเดนจุดดอยของโครงสรางแบบแบงปนการบริการลูกขายและแมขาย

จุดเดนของโครงสรางแบบแบงปนการบริการ

ลูกขายและแมขาย

จุดดอยของโครงสรางแบบแบงปนการบริการ

ลูกขายและแมขาย

1. ในการทํางานสามารถกระจายกันทํางาน

ไปยังทุกระบบยอยได

2. หากตองการเพ่ิมประสิทธิภาพการ

ประมวลผลและการใหบริการแมขาย

สามารถเพ่ิมได ทัน ที ไมกระทบตอ

การทํางานของเครื่องลูกขาย

1. การทํางานยั งตองอาศัย การบริการ

จัดการทางดานของเครือขาย สื่อสารผาน

ทาง ทีซีพี ไอพี (TCP/IP) ซ่ึงจําเปนตองมี

การติดตั้งระบบเครือขายไวเพ่ือรองรับ

การใชงาน

2. สิ่งท่ีผูใชงานตองระวังคือความซํ้าซอน

ทางดานบริหารจัดการขอมูล เนื่องจากมี

เครื่องจํานวนมากท่ีอยูบนระบบ

65

การแบงสวนควบคุมการทํางานของซอฟตแวร

สําหรับการพัฒนาซอฟตแวรสามารถแบงสวนของการควบคุมการทํางานไดดังนี้ การแบงสวน

ซอฟตแวรเชิงวัตถุ การแบงสวนซอฟตแวรตามฟงกชันการใชงาน และการควบคุมการทํางานของ

สวนประกอบยอย จะอธิบายดังตอไปนี้

1. การแบงสวนซอฟตแวรเชิงวัตถุ (Object Oriented Decomposition) จะทําการแบงลักษณะ

ของกลุมอ็อบเจ็กตท่ีเหมือนกัน ทําหนาท่ีเดียวกันไวดวยกันซ่ึงมีลักษณะการทํางานแบบฟงกชัน จุดเดน

ของการแบงสวนแบบนี้คือ การทํางานของแตละอ็อบเจ็กตสามารถเปนอิสระตอกัน การเปลี่ยนแปลง

ภายในของแตละอ็อบเจ็กตจะไมสงผลกระทบถึงกัน ทําใหการพัฒนาถูกตองมากข้ึน จากภาพแสดง

ตัวอยางอ็อบเจ็กตและคลาสของระบบสถานีพยากรณอากาศ (Weather Station) ของกลุมอ็อบเจ็กตท่ีมี

ความสัมพันธกัน ไดออกแบบกลุมของอ็อบเจ็กตและคลาสท่ีมีความสัมพันธกันจะมีการข้ึนตอกันนอย ไม

ซํ้าซอน ตองเปนขอมูลเดียว แบงเปน WeatherData GroundThermometer Anemometer

Barometer แตละคลาสไมข้ึนแกกันทําใหเม่ือมีการเปลี่ยนแปลงการทํางานภายในของอ็อบเจ็กตจะไม

สงผลกระทบตออ็อบเจ็กตอ่ืน ดังภาพท่ี 6.2

ภาพท่ี 6.2 แสดงอ็อบเจ็กต และคลาส ของระบบสถานีพยากรณอากาศ

ท่ีมา : http://www.mhhe.com/engcs

http://www.mhhe.com/engcs

66

2. การแบงสวนซอฟตแวรตามฟงกชันการใชงาน (Function Oriented Decomposition) มี

ลักษณะ ของการแบงตามการประมวลผลของขอมูล การทํางานเปนไปตามลําดับทําใหเขาใจงายตอการ

ทํางาน หากมีการเพ่ิมกระบวนการสามารถทําเพ่ิมไดเลยตามลําดับ สําหรับขอท่ีควรระวังคือไมเหมาะกับ

ระบบงานท่ีตองการประมวลผลแบบโตตอบทันที และอาจจะมีการทํางานท่ีซํ้าซอนได ดังภาพท่ี 6.3

ภาพท่ี 6.3 แสดงการแบงสวนซอฟตแวรตามฟงกชันการใชงาน

จุดเดนของการแบงสวนซอฟตแวรตามฟงกชันการใชงาน คือสามารถนํากระบวนการทํางานแปลง

สภาพของขอมูลและนํากลับไปใชซํ้าได ทีมงานผูพัฒนาระบบซอฟตแวรสามารถทําความเขาใจไดงาย และ

การเพ่ิมกระบวนการทํางานใหมทําไดงายดวยวิธีการเรียงฟงกชันการทํางานตอไปเรื่อยๆ

จุดดอย ของการแบงสวนซอฟตแวรตามฟงกชันการใชงาน คือไมเหมาะกับระบบงานท่ีจําเปนตอง

โตตอบในทันทีขอมูลท่ีสงไปตองเปนรูปแบบเดียวกัน และการประมวลผลท่ีซํ้าซอนอาจจะทําใหเกิด

ขอผิดพลาดได

3. การควบคุมการทํางานของสวนประกอบยอยสวนของการควบคุมระบบนั้นจําเปนตองมีตัว

ควบคุมระบบงานเพ่ือดูแลระบบยอยใหทํางานไดถูกตองแมนยําและมีประสิทธิภาพมากข้ึน สามารถแบง

ไดเปน 2 รูปแบบ ดังนี ้

แบบท่ี 1 การควบคุมแบบศูนยกลาง (Centralized Control) ทําการจัดสรรหนาท่ีใหกับ

ระบบยอย ซ่ึงทําหนาท่ีเปนตัวควบคุมระบบยอยอ่ืนๆ โดยมีการทํางาน 2 ลักษณะ คือ

แบบเรียกและสงกลับ (Call and Return Model) คือ การแบงหนาท่ีการควบคุมกันไปเปน

ลําดับ เชน การเขียนโปรแกรมหลักและโปรแกรมยอย ซ่ึงทางโปรแกรมม่ิงเปนลักษณะภาษาเชิงโครงสราง

เชน ปาสคาล (Pascal), เบสิค (Basic)

แบบการจัดการ (Manager Model) คือการทํางานแบบสั่งการโดยมีระบบสั่งการ 1 ระบบ

นอกจากนั้นจะแบบระบบยอยท่ีมีหนาท่ีเพียงรับคําสั่งจากระบบสั่งการเทานั้น ดังภาพท่ี 6.4

67

ภาพท่ี 6.4 แสดงการควบคุมแบบศูนยกลาง

ท่ีมา : http://courseware.payap.ac.th/docu/mk380/f4.1.htm

แบบท่ี 2 การควบคุมตามเหตุการณ (Event based Control) เปนลักษณะของการควบคุมท่ีเม่ือ

เกิดเหตุการณหนึ่งข้ึนแลวทําใหเหตุการณหนึ่งเกิดข้ึนตามมา เรียกเหตุการณนั้นอีกอยางวา “Event” การ

ควบคุมตามเหตุการณนี้สามารถแบงไดออกเปน 2 แบบคือ เหตุการณแบบกระจาย และเหตุการณ

ขัดจังหวะ

เหตุการณแบบกระจาย มีลักษณะการกระจายคําสั่งออกไปยังระบบยอยทุกระบบโดยระบบยอย

จะทําตามคําสั่ง หนาท่ีงานของระบบตนเองและสงผลกลับคืนมา

ภาพท่ี 6.5 แสดงเหตุการณแบบกระจาย

จากภาพแสดงการควบคุมตามเหตุการณแบบกระจาย โดยเม่ือพิจารณาจากระบบยอย เชน

Fault Manager, Configuration Manager, Power Manager, Communications, Data Collection,

Instruments ระบบยอยท้ังหมดนี้จะไดรับคําสั่งตามท่ีถูกกําหนดโดยโปรแกรม หากระบบยอยไดเปน

ผูรับผิดชอบงานเหลานั้นก็จะทําการตอบสองตอเหตุการณท่ีถูกสงมาและดําเนินการตอไป

http://courseware.payap.ac.th/docu/mk380/f4.1.htm

68

จุดเดนของแบบการควบคุมตามเหตุการณแบบกระจาย คือสามารถเพ่ิมระบบยอยใหมไดงาย

เพียงเพ่ิมขอมูลระบบยอยใหมในตัวเก็บเหตุการณและขอความ (Even & Massage Handler) แตพบวามี

ขอจํากัดบางประการเก่ียวกับเหตุการณท่ีอาจจะซํ้าซอนทําใหระบบประมวลผลผิดพลาดได

เหตุการณ ขัดจังหวะ จะคอยจัดสรรระบบงานยอยให ทํางานตามคําสั่ง โดยจัดเรียงตาม

ความสําคัญของเหตุการณ หรือชุดคําสั่งท่ีไดถูกสรางข้ึนมา แบบนี้จึงเหมาะสมกับระบบงานแบบเวลาจริง

(Real Time) เพราะจะทําใหงานท่ีสําคัญนั้นไดประมวลผลกอนอยางถูกตอง จากภาพแสดงการขัดจังหวะ

นั้น สามารถผสมผสานวิธีการเรียกใชงานระบบยอยแบบการควบคุมแบบศูนยกลาง เพ่ือใหทํางานรวมกัน

ได จุดเดนของการทํางานแบบขัดจังหวะ คือการทํางานท่ีรวดเร็วเพ่ือตอบสนองตอเหตุการณในทันที จุด

ดอยคือโปรแกรมจะมีความซับซอนสูง ตรวจหาขอผิดพลาดไดลําบาก ดังภาพท่ี 6.6

ภาพท่ี 6.6 แสดงการขัดจังหวะของโปรเซส

ระบบประมวลผลของซอฟตแวร

ระบบประมวลผลของซอฟตแวรสามารถแสดงออกมาเปนโครงสรางหรือรูปแบบจําลองในงานนั้น

แบงเปน 3 ระบบ คือ ระบบประมวลผลขอมูล ระบบประมวลผลรายการขอมูล และระบบประมวลผล

ตามเหตุการณ สามารถอธิบายไดดังนี้

1. ระบบประมวลผลขอมูล จะมีการเก็บขอมูลไวประมวลผล ณ ชวงเวลาใดเวลาหนึ่งเสมอ โดย

ไมรบกวนการทํางานของผูใช เรียกอีกอยางวา การประมวลผลแบบกลุม (Batch Processing) ประกอบ

ไปดวยสวนสําคัญ 4 สวน คือ 1) สวนนาํเขาขอมูล 2) ประมวลผลขอมูล 3) สวนแสดงผลขอมูล และ 4)

ฐานขอมูล ดังภาพท่ี 6.7

69

ภาพท่ี 6.7 แสดงระบบประมวลผลขอมูล

2. ระบบประมวลผลรายการขอมูล ระบบจะมีฐานขอมูลเปนศูนยกลางการประมวลผลคํารองขอ

ขอมูลจากผูใชงานท้ังหมด เปนรูปแบบท่ีรองรับผูใชงานหลายคนพรอมกัน ดังภาพท่ี 6.8

ภาพท่ี 6.8 แสดงระบบประมวลผลรายการขอมูล

3. ระบบประมวลผลตามเหตุการณ คือระบบจะทํางานกับทุกเหตุการณท่ีกระตุน โดยเหตุการณ

นั้น คือการเขียนโปรแกรมเพ่ือสั่งงานนั่นเอง ระบบนี้มักจะอยูในคอมพิวเตอรสวนบุคคล เชน ระบบ

สนทนาออนไลน โปรแกรมท่ี 1, 2 และ 3 เม่ือมีคูสนทนาสงขอความมาระบบจะทําการขัดจังหวะ และ

แจงเตือนทันที ดังภาพท่ี 6.9

ภาพท่ี 6.9 แสดงระบบประมวลผลตามเหตุการณ

ระบบ

สวนนําเขาขอมูล ประมวลผลขอมูล สวนแสดงผล

ฐานขอมูล

I/O Processing Application Transaction Databased

โปรแกรม 1



เหตุการณ

สงขอความ

70

บทสรุป

การออกแบบเชิงสถาปตยกรรมสําหรับซอฟตแวรทําใหเห็นภาพโดยรวมของการทํางานในระบบ

การจัดการโครงสรางท่ีจําเปนตองการในระบบ เชน โครงสรางแบบแบงปนขอมูล สําหรับการใชขอมูล

โดยฐานขอมูลเดียวกัน การศึกษาถึงจุดเดนและจุดดอยของโครงสรางสถาปตยกรรมแตละแบบ

โครงสรางแบบแบล็คบอรด เหมาะสมท่ีจะใชกับการมีขอมูลขนาดใหญ เพ่ือเปนการลดเวลาการทํางาน

ของโปรแกรมลง จุดดอยอาจจะไมสามารถทํางานรวมกับโครงสรางอ่ืนได โครงสรางแบบแบงปนการ

บริการลูกขายและแมขายนั้นเปนท่ีนิยมอยางแพรหลาย แตหลักการทํางานคอนขางซับซอนและตอง

บริหารจัดการภายใต ทีซีพี ไอพี การแบงสวนควบคุมการทํางานของซอฟตแวร แบงเปน 3 แบบ คือ

การแบงสวนซอฟตแวรเชิงวัตถุ การแบงสวนซอฟตแวรตามฟงกชันใชงาน และการควบคุมการทํางาน

ของสวนประกอบยอย สําหรับระบบประมวลผลซอฟตแวร แบงไดเปน 3 ระบบ คือ ระบบการ

ประมวลผลขอมูล ระบบการประมวลผลรายการขอมูล ระบบประมวลผลตามเหตุการณ ท้ังหมดท่ีกลาว

มาขางตนนี้ลวนมีความสําคัญกับการจัดการโครงสรางซอฟตแวรเชิงสถาปตยกรรมจําเปนจะตองพิจารณา

เพ่ือใหการพัฒนาซอฟตแวรทํางานถูกตองตามหนาท่ีไดอยางสมบูรณ


1. จงอธิบายรูปแบบโครงสรางการควบคุมแบบศูนยกลาง

2. จงอธิบายจุดเดนและจุดดอยของการควบคุมแบบศูนยกลาง

3. จงอธิบายรูปแบบโครงสรางซอฟตแวรเชิงสถาปตยกรรมตามลักษณะการใชงาน

4. จงอธิบายจุดเดนและจุดดอยของการควบคุมตามเหตุการณแบบกระจาย

5. จงอธิบายการจัดการโครงสรางซอฟตแวรเชิงสถาปตยกรรม ในรูปแบบการพัฒนาซอฟตแวร

เชิงวัตถุ

6. จงอธิบายการแบงสวนของซอฟตแวรเชิงวัตถุ

7. จงอธิบายการแบงสวนของซอฟตแวรตามฟงกชันการใชงาน

8. จงอธิบายจุดเดนจุดดอยของการแบงสวนการควบคุมการทํางานระบบยอย

9. จงอธิบายหลักการระบบประมวลผลตามเหตุการณ

10. จงอธิบายจุดเดนจุดดอยของการขัดจังหวะของโปรเซส

71

อางอิง






คเชนทร ซอนกลิ่น,"ระบบสารสนเทศแบบกระจาย Distributed Information System" คนวันท่ี 22

มกราคม 2559, จาก http://www.dailymail.co.uk/sciencetech/article-2219188/Inside-

Google-pictures-gives-look-8-vast-data-centres.html




(มหาชน).








what-cmmi.








Company.


73



1. ความหมายของวิศวกรรมความตองการ

2. กระบวนการดานวิศวกรรมความตองการ

3. ข้ันตอนกระบวนการดานวิศวกรรมความตองการ

4. การจัดการความตองการ


1. นักศึกษาสามารถอธิบายความหมายของวิศวกรรมความตองการ กระบวนการดานวิศวกรรม

ความตองการ ข้ันตอนกระบวนการดานวิศวกรรมความตองการและการจัดการความตองการได

2. นักศึกษาสามารถวิเคราะหความตองการได

3. นักศึกษาสามารถแสดงกระบวนการดานวิศวกรรมความตองการได



1.1 วิธีการสอนแบบบรรยาย เริ่มจากอธิบายความหมายวิศวกรรมความตองการ

กระบวนการดานวิศวกรรมความตองการ ข้ันตอนกระบวนการดานวิศวกรรมความตองการ การจัดการ

ความตองการ




2.1 แสดงตัวอยางเทคนิคท่ีสําคัญสําหรับการเก็บรวบรวมความตองการ

2.2 แบงกลุมอภิปรายเรื่องการสรางแบบจําลองแบบวิเคราะหความตองการ





74





75

บทท่ี 7

วิศวกรรมความตองการ

ในบทนี้จะกลาวถึงกระบวนการตางๆ ทางวิศวกรรมเพ่ือบริหารจัดการความตองการ ซ่ึงความ

ตองการของระบบนั้นเปนสิ่งจําเปนท่ีตองนํามาวิเคราะหเพ่ือพัฒนาระบบซอฟตแวรท่ีใชงานได ทาง

วิศวกรรมซอฟตแวรนั้นมีกระบวนการ เชน คนหาความตองการของระบบ แบงประเภทความตองการของ

ระบบ เรียงลําดับความสําคัญของความตองการของระบบ และจัดเตรียมเอกสาร นอกจากนี้ข้ันตอนท่ี

สําคัญของกระบวนการดานวิศวกรรมความตองการนั้นไดแบงเปน 4 ข้ันตอน คือ ข้ันตอนท่ี 1 สกัดความ

ตองการของระบบ ข้ันตอนท่ี 2 วิเคราะหความตองการ ข้ันตอนท่ี 3 กําหนดความตองการหลังจากท่ี

ตนแบบไดรับการยอมรับจากทุกฝาย ข้ันตอนท่ี 4 ตรวจสอบความตองการ และประเด็นสุดทายคือการ

จัดการความตองการของนักวิศวกรซอฟตแวรท่ีจะเลือกวิธีใหเหมาะสมกับงาน เพ่ือใหซอฟตแวรใชงานท่ี

ตรงกับความตองการมากท่ีสุด

ความหมายของวิศวกรรมความตองการ

เนื่องจากกระบวนการในการบริหารจัดการความตองการของระบบนั้น มีความสําคัญตอการ

พัฒนาระบบจึงจําเปนท่ีจะตองมีนักวิศวกรความตองการ เพ่ือมาจัดการกระบวนการดังกลาวไดอยาง

เหมาะสม

วิศวกรรมความตองการ คือ กระบวนการท่ีจะทําใหวิศวกรซอฟตแวร สามารถเขาใจถึงความ

ตองการของลูกคาอยางแทจริง ดวยการวิเคราะหความตองการ นิยาม ตลอดจนตรวจสอบความตองการ

เหลานั้น เพ่ือเปนการสรางกําหนดความตองการดานซอฟตแวร

กระบวนการดานวิศวกรรมความตองการ

ภายหลังจากท่ีทําการศึกษาความเปนไปไดของระบบ ข้ันตอนตอไปคือการเก็บรวบรวมความ

ตองการของระบบจากผูท่ีเก่ียวของ โดยมีกระบวนการดานวิศวกรรมความตองการดังตอไปนี้

1. คนหาความตองการของระบบ (Requirements discovery) เปนกิจกรรมท่ีเกิดข้ึนโดยผู

วาจางใหพัฒนาโปรแกรมและทีมงาน ทําการคนหาสวนของการทํางานหลักของระบบ เก่ียวกับการทํางาน

และเทคนิคท่ีจําเปนตองใช

2. แบงประเภทของความตองการของระบบ ( Requ i r emen t s c l a s s i f i c a t i on and

organization) เปนกิจกรรมท่ีเกิดข้ึนโดยทีมงานจะแบงงานออกเปนสวนยอย อาจจะใชวิธีการแบงกลุม

ของงานท่ีมีลักษณะเหมือนกันรวมเขาใวดวยกันเปนหมวดหมู จากนั้นจะทําการจัดสรรงานใหกับทีมงานท่ี

มีหนาท่ีแตกตางกันไป

76

3. เรียงลําดับความสําคัญของความตองการของระบบ (Requirements prioritization and

negotiation) กิจกรรมนี้จะทําการจัดเรียงลําดับ ความสําคัญของแตละความตองการจากผูท่ีเก่ียวของ

ท้ังหมด

4. จัดเตรียมเอกสาร (Requirements specification) ข้ันตอนนี้เปนการจัดทําเอกสาร ท่ีได

รวบรวมมาเพ่ือสงใหผูท่ีมีสวนเก่ียวของรับทราบและแกไขปรับปรุงตอไป กระบวนการดานวิศวกรรมความ

ตองการ ดังภาพท่ี 7.1

ภาพท่ี 7.1 แสดงกระบวนการดานวิศวกรรมความตองการ

ท่ีมา : http://www.SoftwareEngineering-9.com/Web/Requirements

ข้ันตอนกระบวนการดานวิศวกรรมความตองการ

ทีมงานพัฒนาซอฟตแวรจะพิจารณาทําข้ันตอนกระบวนการดานวิศวกรรมความตองการ ซ่ึง

แบงเปน 4 ข้ันตอน ดังนี้ ข้ันตอนท่ี 1 สกัดความตองการของระบบ ข้ันตอนท่ี 2 วิเคราะหความ

ตองการ ข้ันตอนท่ี 3 กําหนดความตองการหลังจากท่ีตนแบบไดรับการยอมรับจากทุกฝาย ข้ันตอนท่ี 4

ตรวจสอบความตองการ จะอธิบายดังตอไปนี้

ข้ันตอนท่ี 1 สกัดความตองการของระบบ เปนการรวบรวมความตองการของระบบ ผูพัฒนา

ระบบจะตองทําความเขาใจกับปญหาท่ีผูใชงานตองการ ตลอดถึงวิเคราะหความจําเปนและเรียงลําดับ

ความสําคัญ โดยอาจจะเริ่มนําทีมผูพัฒนาระบบพบเจอหรือประชุมกับลูกคาเพ่ือเก็บขอมูลท่ีสําคัญ

เบื้องตน การสกัดความตองการโดยท่ัวไปนั้นสามารถทําได ดังตารางท่ี 7.1

http://www.softwareengineering-9.com/Web/Requirements

77

ตารางท่ี 7.1 ตารางแสดงการสกัดความตองการและแนวทางแกไข

ปญหาท่ีพบจากการสกัดความตองการ แนวทางแกไข

1. กรณีของความตองการของผู ใชงานนั้นไม

ชัดเจน กวางเกินไป คลุมเครือ

2. นิยามของงานเดิม งานระบบเดิมนั้นอาจจะมี

ศัพทเฉพาะผูพัฒนาอาจจะมีปญหาในการเก็บ

ขอมูลได

3. ความตองการของผูใชงานแตละคนอาจจะ

แตกตางกันไป

1. นักวิศวกรซอฟตแวรอาจจะตองทําเปนลาย

ลักษณอักษรถึงการเก็บขอมูลเหลานั้น อาจจะ

ตองระบุปญหาขอบเขตท่ีชัดเจน

2. การใชนิยามศัพทเฉพาะงานนั้นอาจจะตองทํา

คําอธิบายศัพทเฉพาะข้ึนมา

3. การสรางความสัมพันธของความตองการให

เกิดข้ึนเพ่ือจัดกลุมหรือแยกประเภทความ

ตองการเหลานั้น ท้ั งนี้ เพ่ือเป าหมายการ

พัฒนาท่ีไดซอฟตแวรท่ีมีคุณภาพ

เทคนิคท่ีสําคัญสําหรับการเก็บรวบรวมความตองการ

1. เทคนิคการสัมภาษณ ( Interview) เปนเทคนิคท่ีเปนท่ีนิยมกันมาอยางยาวนาน เนื่องจาก

เปนการปฏิบัติท่ีงายท่ีสุดท่ีไดขอมูลกลับมาอยางคุมคา อีกท้ังยังสามารถโนมนาวผูถูกสัมภาษณไดอีกทาง

หนึ่งดวย

2. การแสดงลําดับเหตุการณ (Scenario) เปนการจําลองเหตุการณท่ีอาจจะเกิดข้ึนได ดังนั้นจึง

เปนคุณลักษณะท่ีดีท่ีจะนํามาเขียนยูสเคส (Use Case) สําหรับการพัฒนาระบบตอไป

3. การสรางตนแบบ (Prototype ) เปนเทคนิคหนึ่งท่ีเปนท่ีนิยมมากเนื่องจากจุดเดนของการ

สรางตนแบบ นั้นทําใหท้ังผูพัฒนาระบบและผูใชงานสามารถเห็นภาพรวม ท่ีคอนขางจะสมบูรณของระบบ

ไดชัดเจนมากท่ีสุด

4. การสังเกต (Observation) เปนวิธีการท่ีตองมีคาใชจายคอนขางสูงแตไดผลลัพธในทางบวก

นอยกวาแบบอ่ืน แตจุดประสงคท่ีสําคัญของแบบการสังเกตนี้เพ่ือท่ีจะหาขอบกพรองสําหรับระบบเดิม ซ่ึง

บางครั้งอาจจะไมไดคําตอบจากผูใชงานอยางครบถวน

ข้ันตอนท่ี 2 วิเคราะหความตองการ เปนข้ันตอนท่ีนักวิศวกรระบบจะตองทําการจัดกลุมของ

ความตองการเหลานั้น และเรียงลําดับความสําคัญของความตองการ หากพบความตองการใดท่ีไม

สอดคลองกันก็ทําการแกปญหาเก่ียวกับความขัดแยงเหลานั้น ตั้งแตแรกจากนั้นอาจจะทําเปนตนแบบเพ่ือ

เสนอใหลูกคาเห็นภาพโดยรวมของระบบ เปนการสรางความเชื่อม่ันใหกับลูกคาอีกทางหนึ่งดวย

78

ตรวจสอบความตองการของระบบ

การตรวจสอบความถูกตองของความตองการนั้นมีข้ันตอนดังตอไปนี้

1. เริ่มตนทําความเขาใจกับปญหาท่ีเกิดข้ึน การพัฒนาระบบทีมผูพัฒนาระบบควรตรวจสอบ

ความตองการของระบบนั้นสอดคลองกับปญหาหรือไม

2. สรางตนแบบจากความตองการของระบบ เปนการตรวจสอบเพ่ือนําไปวางแผนในการพัฒนา

ระบบตอไป

3. หากมีการปรับปรุงระบบ สามารถทําการเปลี่ยนแปลงระบบใหตรงกับความตองการจาก

ผูใชงาน

4. ในบางครั้งอาจจะตองทําความเขาใจระบบกันใหมท้ังหมด และทีมงานสามารถเปลี่ยนความ

ตองการของระบบไดในข้ันตอนตรวจสอบความตองการของระบบ ดังภาพท่ี 7.2

ภาพท่ี 7.2 แสดงตรวจสอบความตองการของระบบ

กิจกรรมท่ีเกิดข้ึนสําหรับข้ันตอนนี้สามารถแบงไดเปน 2 กิจกรรม

กิจกรรมการแบงกลุมความตองการ (Requirement Classification) ซ่ึงสามารถแบงเปนความ

ตองการท่ีมีหนาท่ีหลักและการสรางแบบจําลองความตองการ ดังจะอธิบายตอจากนี้

1. ความตองการท่ีเปนหนาท่ีหลัก คือจุดมุงหมายของการพัฒนาซอฟตแวรใหสามารถทํางาน

ได ความตองการท่ีเก่ียวกับกระบวนการกลุมลําดับแรกๆ โดยสามารถเรียงความสําคัญของความตองการ

โดยท่ัวไปจะเปนสวนของระดับความจําเปน สูง กลาง ต่ํา และสวนละเวนแบงกลุมตามขอบเขตความ

ตองการ แบงกลุมตามการเปลี่ยนแปลงความตองการ ขอบเขตความตองการบางอยางไมสามารถ

เปลี่ยนแปลงได แตบางอยางก็สามารถเปลี่ยนแปลงได

2. กิจกรรมสรางแบบจําลองความตองการ เปนการสรางแบบจําลองแนวคิด เพ่ือใชสําหรับการ

รวบรวมความตองการท้ังหมดมาใหเห็นภาพโดยรวม กิจกรรมนี้ยังสงผลใหเห็นถึงความผิดพลาดของระบบ

ท่ีอาจจะเกิดข้ึนไดอีกดวย

ทําความเขาใจกับ

ปญหา

สรางตนแบบจาก


ปรับปรงุใหตรงกับ


เปลี่ยนความ

ตองการของระบบ

ระยะเวลา

79

ข้ันตอนท่ี 3 กําหนดความตองการหลังจากท่ีตนแบบไดรับการยอมรับจากทุกฝาย จัดทําเปน

เอกสารขอกําหนดความตองการของระบบ สรางคํานิยาม ขอกําหนดของความตองการระบบ ท้ังนี้เพ่ือ

สรางความเขาใจและสามารถนํามาตรวจสอบความถูกตองภายหลังได เอกสารท่ีจําเปนตอการกําหนด

ความตองการของระบบมีดังนี้

1. เอกสารนิยามระบบ เปนเอกสารท่ีกําหนดคํานิยามเฉพาะท่ีใชกับระบบ เชน ศัพทท่ี

เก่ียวกับทางการแพทย วิทยาศาตร วิศวกรรมศาสตร

2. เอกสารความตองการของระบบ เปนเอกสารท่ีระบุถึงความตองการของระบบโดยไดผานการ

สังเคราะห ขอมูล ระบุแหลงท่ีมาของขอมูล

3. เอกสารขอกําหนดความตองการทางดานซอฟตแวร

ข้ันตอนท่ี 4 ตรวจสอบความตองการ หลังจากท่ีทําข้ันตอนท่ี 3 เสร็จสมบูรณแลวนั้น ข้ันตอนนี้จะ

เปนการตรวจสอบเพ่ือใหเกิดความเท่ียงตรง สอดคลองกันของการพัฒนาระบบ ความครบถวนสมบรูณ

จากนั้นใหทุกฝายไดรับทราบและทําการตรวจสอบความถูกตองรวมกันลักษณะท่ีพึงตรวจสอบมีดังตอไปนี้

1. ความเท่ียงตรง เปนการตรวจสอบฟงกชันการทํางานพ้ืนฐาน ตรวจสอบการใชงานวาถูกตอง

สมบูรณหรือไม

2. ความสอดคลอง เปนการตรวสอบเอกสารกับระบบงานจริงวามีสวนใดถูกตองตรงกันหรือไม

3. ความครบถวนสมบูรณ

4. ความเปนไปไดจริงจากความตองการของผูใชงาน อาจจะทําการพิจารณาถึงความสอดคลอง

กันของตนแบบ

การจัดการความตองการ

สิ่งท่ีนักวิศวกรซอฟตแวรจะตองดําเนินการคือการจัดการความตองการ ซ่ึงจําเปนตองบริหาร

จัดการความตองการท่ีไดมานั้นอยางดีท่ีสุด การรวบรวมความตองการรวมกัน มีหลายวิธีการในการ

รวบรวมความตองการรวมกัน แตละวิธีใชวิธีท่ีแตกตางกันเล็กนอย แตทุกวิธีมีการประยุกตขอแนะนํา

เบื้องตนตอไปนี้

1. การประชุมรวมกันท้ังฝายนักวิศวกรซอฟตแวร และลูกคา ผูบริหาร ในการประชุมทุกครั้ง

จําเปนตองมีการกําหนดกฎเกณฑในการเตรียมตัวและหัวขอสําหรับการเขารวมประชุมในครั้งนั้นๆ

2. มีวาระในการประชุมท่ีเปนทางการ ไมสอดแทรกประเด็นท่ีไมจําเปนตอการพัฒนาระบบ

80

3. ในการประชุมจําเปนตองมีประธานในการประชุม ผูอํานวยความสะดวก เปนผูควบคุมการ

ประชุม เลขาผูจดบันทึก

4. หากพบปญหาในการทํางาน ปรึกษาและเสนอคําตอบ แนวทางแกปญหา

โดยมีประเด็นท่ีสําคัญเพ่ือท่ีจะนําไปสูผลสัมฤทธของการพัฒนาซอฟตแวรท้ังหมด 4 ประเด็นดังนี้

1) บุคคลท่ีเก่ียวของกับระบบ 2) รวบรวมขอคิดเห็นจากทุกแหลงขอมูลบุคคล 3) การสรางความสามัคคี

และรวมมือกันทํางาน 4) การเตรียมคําถาม

บุคคลท่ีเก่ียวของกับระบบ ผูบริหารโครงการจําเปนจําตองทราบถึงผูท่ีมีสวนเก่ียวของกับการ

พัฒนาโครงการ เชน ผูจัดการดําเนินธุรกิจ ผูจัดการผลิตภัณฑ บุคลากรทางตลาด ลูกคาภายในและ

ภายนอก ผูใชงานสุดทาย จนกระท้ังท่ีปรึกษาหนวยงานหรือโครงการ

รวบรวมขอคิดเห็นจากทุกแหลงขอมูลบุคคล เม่ือทําการรวบรวมขอมูลจากท่ีสวนงานแลว

จําเปนตองนํามาคัดกรองสวนท่ีจําเปนและไมจําเปนตอการพัฒนาระบบ ใหครอบคลุมทุกแงมุม

การสรางความสามัคคีและรวมมือกันทํางาน หนาท่ีหลักของนักวิศวกรความตองการคือ สราง

แรงจูงใจกับทีมงานใหพัฒนาซอฟตแวรอยางมีประสิทธิภาพ พยายามมองหาจุดเดนของทีมงานและ

ขอบกพรองของทีมงานเพ่ือสรางความสัมพันธท่ีดี

การเตรียมคําถาม การตั้งคําถามท่ีดีสงผลใหไดมาซ่ึงคําตอบของระบบท่ีชัดเจนถูกตอง ดังนั้นกอน

การตั้งคําถามควรมีการไตรตรองอยางถ่ีถวน หลีกเลี่ยงคําถามท่ีกอใหเกิดความขุนของหมองใจ หรือ

คําถามท่ีคลุมเครือกระอักกระอวนท่ีจะตอบคําถามนั้น

บทสรุป

วัตถุประสงคหลักของวิศวกรรมความตองการคือ การเก็บรวบรวมขอมูลความตองการของระบบ

และกําหนดสิ่งท่ีเปนไปไดตอการพัฒนาซอฟตแวร ในบางครั้งการสรางแบบจําลองข้ึนมาเพ่ือใหเห็นภาพท่ี

ชัดเจนจึงเปนสวนท่ีสําคัญตอการพัฒนาระบบ และสิ่งท่ีสําคัญคือการตรวจสอบวาซอฟตแวรนั้นตรงกับ

ความตองการหรือไม นักวิศวกรซอฟตแวรตองคํานึงถึง การสกัดความตองการ เปนกระบวนการดาน

วิศวกรรมความตองการ เชน การคนหาความตองการของระบบ เปนสิ่งแรกท่ีควรจะตองใหมีความชัดเจน

ท่ีสุด โดยการไดมาซ่ึงความตองการของผูใชงานระบบนั้นอาจจะตองมีข้ันตอนกระบวนการดานวิศวกรรม

ความตองการ เชน เทคนิคสําหรับการเก็บรวบรวมความตองการ เทคนิคการสัมภาษณ เปนวิธีการท่ีลงทุน

นอยแตไดขอมูลมาก ในกรณีท่ีผูใชงานไมสะดวกในการใหขอมูลสัมภาษณ ผูพัฒนาระบบอาจจะตองใช

81

เทคนิควิธีการสังเกต เม่ือไดความตองการจากผูใชงานแลวนักวิศวกรซอฟตแวรจําเปนจะตองวิเคราะห

ความตองการเหลานั้น ในบางครั้งพบวาจําเปนจะตองเปลี่ยนความตองการของระบบหลัก สามารถพูดคุย

กับผูใชงานและชี้แจงถึงขอเท็จจริงของการพัฒนาระบบ ภายหลักจากท่ีทุกฝายรับทราบถึงความตองการ

ของระบบอยางแทจริง นักวิศวกรซอฟตแวรจะตองกําหนดความตองการและสรางตนแบบเพ่ือใหทุกฝาย

ไดมองเห็นภาพรวมท่ีชัดเจนและเขาใจตรงกัน สิ่งท่ีสําคัญอีกประการคือการตรวจสอบความตองการนั้น

เรียงลําดับความสําคัญของความตองการ เพ่ือใหการพัฒนาซอฟตแวรไดตรงกับความตองการของผูใชงาน

มากท่ีสุด


1. จงอธิบายรูปแบบของการเก็บรวบรวมความตองการโดยใชวิธีการสัมภาษณ และบอกจุดเดน

จุดดอยของวิธีดังกลาว

2. จงอธิบายกระบวนการวิศวกรรมความตองการ

3. จงอธิบายจุดเดน จุดดอยของกระบวนการวิศวกรรมความตองการ

4. จงพัฒนาชุดเครื่องมือท่ีชวยในการรวบรวมหนาท่ีการทํางาน ชุดเครื่องมือควรรวมถึงชุด

แนะนําแนวทางสําหรับดําเนินการประชุมรวบรวมความตองการ และเครื่องมือท่ีชวยสรางรายงานและ

ขอความแยกยอยท่ีชวยนิยามความตองการ

5. วิศวกรรมระบบอาจมีท่ีมาจากแหลงตอไปนี้คือ นักพัฒนาซอฟตแวร(System Developer)

ลกูคา หรือจากองคกรภายนอก จงเปรียบเทียบขอดีและขอเสียของแตละแหลงดังกลาว จากนั้นบรรยาย

ถึงลักษณะของนักวิศวกรในอุดมคติ

6. จงอธิบายถึงหนาท่ีของนักวิศวกรซอฟตแวรตอการกําหนดความตองการหลังจากท่ีตนแบบได

รับการยอมรับจากทุกฝาย จําเปนตองสรางเอกสารอะไรบาง

7. จงอธิบายหลักการจัดการความตองการ

8. จงตั้งคําถามสําหรับใชกับเทคนิคการสัมภาษณผูใชงานระบบ อยางนอย 5 คําถาม

9. จงอธิบายความสําคัญของการสรางเอกสารเพ่ือยืนยันความตองการระหวางผูใชงาน และ

ผูพัฒนาระบบ

10. จงอธิบายหนาท่ีของประธาน การประชุมโครงในการรวบรวมความตองการรวมกัน

82

อางอิง












(มหาชน).








what-cmmi.








Company.


83

Borland. “CaliberRM Enterprise Software Requirements Management System”.(2012) ,

คนวันท่ี 26 มกราคม 2559, จาก http://www.Borland.com/us/products

Rational Software.2005. “Requirements Management with Use Case”.Boston,

Massachusetts, Addison-Wesley

85



1. วิธีการสรางแผนภาพสําหรับการอธิบายระบบ

2. แผนภาพในการวิเคราะหระบบ

3. เครื่องมือชวยในการอธิบายการประมวลผล

4. การเปรียบเทียบแผนภาพการไหลของขอมูลกับแผนภาพยูสเคส

5. การเปรียบเทียบแผนภาพการไหลของขอมูลกับคลาส


1. นักศึกษาสามารถอธิบายความหมายวิธีการสรางแผนภาพสําหรับการอธิบายระบบ แผนภาพ

ในการวิเคราะหระบบ เครื่องมือชวยในการอธิบายการประมวลผลได

2. นักศึกษาสามารถอธิบายการเปรียบเทียบแผนภาพการไหลของขอมูลกับแผนภาพยูสเคส

การเปรียบเทียบแผนภาพการไหลของขอมูลกับคลาส

3. นักศึกษาสามารถอธิบายประโยชนของแผนภาพในการวิเคราะหได



1.1 วิธีการสอนแบบบรรยาย เริ่มจากการอธิบายถึงความหมายวิธีการสรางแผนภาพ

สําหรับการอธิบายระบบ แผนภาพในการวิเคราะหระบบ เครื่องมือชวยในการอธิบายการประมวลผล

การเปรียบเทียบแผนภาพการไหลของขอมูลกับแผนภาพยูสเคส การเปรียบเทียบแผนภาพการไหลของ

ขอมูลกับคลาส




2.1 แสดงตัววิธีการสรางแผนภาพสําหรับการอธิบายระบบ

2.2 แบงกลุมอภิปรายเรื่องประโยชนของแผนภาพในการวิเคราะห จุดเดน จุดดอย


86








3. วัดเจตคติจากการสังเกตพฤติกรรมความกระตือรือรนในการทํากิจกรรมและคุณภาพของ

งาน

87

บทท่ี 8

แผนภาพและการอธิบายระบบ

ในบทนี้จะกลาวถึงการเขียนแผนภาพและการอธิบายระบบ ซ่ึงเปนอีกข้ันตอนหนึ่งท่ีสําคัญ

สําหรับนักวิศวกรซอฟตแวรท่ีจะตองทําการอธิบายผลลัพธท่ีไดจากการวิเคราะหระบบ โดยแทน

สัญลักษณใหสามารถเขาใจได วิธีการสรางแผนภาพสําหรับการอธิบายนั้น เชน แผนภาพการไหลของ

ขอมูล ตนไมแสดงการตัดสินใจ เทคนิคการสรางแผนภาพเชิงอ็อบเจ็กต เปนตน นอกจากนี้การสราง

แผนภาพในการวิเคราะห เชน แผนภาพการไหลของขอมูล แผนภาพคอนเท็กซ สําหรับเครื่องมือ

ชวยในการอธิบายการประมวลผลจําเปนจะตองเขียนแทนดวยสัญลักษณเพ่ือการทําความเขาใจท่ีตรงกัน

ทุกฝาย อีกท้ังผูท่ีนําระบบไปพัฒนาตอสามารถศึกษาขอมูลจากระบบงานเดิมไดถูกตอง สุดทายเพ่ือให

เห็นการเขียนแทนดวยสัญลักษณท่ีชัดเจนข้ึนจะแสดงการเปรียบเทียบแผนภาพการไหลของขอมูลกับ

แผนภาพยูสเคส และการเปรียบเทียบแผนภาพการไหลของขอมูลกับคลาส เพ่ือใหนักวิศวกรซอฟตแวรใช

แผนภาพและการอธิบายระบบไดอยางถูกตอง

วิธีการสรางแผนภาพสําหรับการอธิบายระบบ

การเขียนแผนภาพสําหรับการอธิบายระบบนี้ มีความสําคัญในการชวยใหนักวิศวกรซอฟตแวร

สามารถทําความเขาใจและวิเคราะหระบบไดอยางถูกตอง เทคนิคสําหรับการสรางแผนภาพสําหรับ

อธิบายระบบมีดังนี้

แผนภาพการไหลของขอมูล ซ่ึงเปนแผนภาพท่ีใชเปนการสื่อท่ีชวยใหนักวิศวกรซอฟตแวรทํา

การวิเคราะหระบบไดงายข้ึนและสรางความเขาใจตรงกันระหวางนักวิศวกรซอฟตแวรและผูใชงานระบบ

อีกดวย

วิธีการสรางตนไมแสดงการตัดสินใจ เปนอีกวิธีหนึ่งท่ีใชเทคนิคท่ีเขียนอธิบายระบบข้ันตอนใด

ข้ันตอนหนึ่งโดยแสดงเหตุการณ เง่ือนไขท่ีจะเกิดข้ึนอยางมีข้ันตอนเพ่ือใหเขาใจระบบไดงายข้ึน

แผนภาพเชิงอ็อบเจ็กตเปนท่ีรูจักกันดีในการสรางความเขาใจสื่อถึงระบบการทํางานของอ็อบเจ็กต

คลาส และลําดับเหตุการณท่ีเกิดข้ึนในระบบ

สําหรับการเลือกใชวิธีการสรางแผนภาพสําหรับการอธิบายระบบใหเหมาะสมกับรูปแบบท่ีใชใน

การวิเคราะหระบบนั้น ประกอบกับเครื่องมือท่ีสรางแผนภาพ ดังตารางท่ี 8.1

88

ตารางท่ี 8.1 ตารางแสดงเทคนิคท่ีใชในการวิเคราะหระบบและเครื่องมือ

เทคนิคท่ีใช รูปแบบท่ีใชในการวิเคราะห

ระบบ เครื่องมือ

การวิเคราะหเชิงโครงสราง แผนภาพการไหลของขอมูล ตนไมแสดงการตัดสินใจ

ตารางการตัดสินใจ

ภาษาเชิงโครงสราง

การวิเคราะหเชิงอ็อบเจ็กต แผนภาพยูสเคส แผนภาพแสดงสถานะ

แผนภาพในการวิเคราะหระบบ

วิธีการสรางแผนภาพสําหรับการอธิบายระบบ มีรายละเอียดท่ีสําคัญดังนี้

1. แผนภาพการไหลของขอมูล เปนการเสนอขอมูลโดยอาศัยการใชรูปภาพหรือสัญลักษณ ใน

ลักษณะแผนภาพระดับบนสุด และระบบยอยของการประมวลผล ในสวนของแผนภาพนั้นไดแสดงการ

จัดเก็บขอมูลในรูปแบบของแฟมขอมูล และแสดงรายละเอียดในสวนของขอมูลท่ีจําเปนตองมี เรียวา

พจนานุกรมขอมูล (Data Dictionary) เพ่ือประกอบในการอธิบายรายละเอียดของการวิเคราะหระบบดวย

สัญลักษณท่ีใชแทนการเขียนแผนภาพการไหลของขอมูลท่ีนิยมในการเขียนแผนภาพการไหลของ

ขอมูล คือ สัญลักษณการประมวลผล สัญลักษณการไหลของขอมูล สัญลักษณการเก็บขอมูล และ

สัญลักษณแทนสิ่งท่ีอยูภายนอกระบบ ดังจะอธิบายตอไปนี้

สัญลักษณการประมวลผล จะเปนการเขียนสัญลักษณแทนโดยใชสัญลักษณวงกลม และเขียน

ขอความกํากับภายในวงกลมดวยชื่อของการประมวลผลนั้น

สัญลักษณการไหลของขอมูล จะเปนการเขียนสัญลักษณแทนโดยใชเสนลูกศร และเขียนขอความ

กํากับดวยชื่อขอมูลท่ีไหลผานเสนลูกศรนั้น เชน การเบิกจายเงิน การเบิกจายอุปกรณ

สัญลักษณการเก็บขอมูล จะเปนการเขียนสัญลักษณแทนโดยใชเสนขนาน 2 เสนมีลักษณะขนาน

กัน ภายในเสนขนานเขียนขอความกํากับดวยชื่อแฟมขอมูลท่ีใชเก็บขอมูล เชน ฐานขอมูลอาจารย

สัญลักษณแทนสิ่งท่ีอยูภายนอกระบบ จะเปนการเขียนสัญลักษณแทนโดยใชรูปสี่เหลื่ยมผืนผา

เขียนขอความกํากับดวยชื่อของสิ่งท่ีอยูภายนอกระบบ เชน นักศึกษา ลูกคา ดังตารางท่ี 8.2

89

ตารางท่ี 8.2 ตารางแสดงสัญลักษณการเขียนแผนงานการไหลของขอมูล

ช่ือสัญลักษณ สัญลักษณ ตัวอยาง

สัญลักษณการประมวลผล

สัญลักษณการไหลของขอมูล

สัญลักษณการเก็บขอมูล

สัญลักษณแทนสิ่งท่ีอยูภายนอก

ระบบ

2. แผนภาพคอนเท็กซ เปนแผนภาพแสดงการไหลของขอมูลในระดับสูงท่ีสุด แสดงถึง

ขอบเขตการทํางานของระบบ และแสดงการเชื่อมตอกันของสิ่งท่ีอยูนอกระบบกับสัญลักษณของการ

ประมวลผล ตัวอยาง ระบบการลงทะเบียนเรียนผานอินเตอรเน็ต มีสิ่งท่ีอยูนอกระบบ คือ นักศึกษา ทํา

การกรอกขอมูลนักศึกษาเขาสูระรบบ และระบบจะแสดงขอมูลการลงทะเบียนกลับมา สวนของอาจารย

ทําการกรอกขอมูลอาจารยเขาสูระรบบ และระบบจะแสดงขอมูลรายวิชากลับมา สวนของเจาหนาท่ี

ทะเบียนทําการกรอกขอมูลหลักสูตรเขาสูระบบ และระบบจะแสดงขอมูลการลงทะเบียนกลับมา


ลูกคา

นักศึกษา

ฐานขอมูลอาจารย

คํานวณ

การเบิกจายเงิน

90

ภาพท่ี 8.1 แสดงระบบการลงทะเบียนผานอินเตอรเน็ต

เคร่ืองมือชวยในการอธิบายการประมวลผล

สําหรับการเขียนอธิบายการประมวลผลนั้นมีวิธีการเขียน 3 วิธี คือ ตนไมแสดงการตัดสินใจ

ตารางการตัดสินใจ และภาษาเชิงโครงสราง จะอธิบายดังนี้

ตนไมแสดงการตัดสินใจ เปนการใชผังตนไมในการเขียนอธิบายการประมวลผล ซ่ึงจะเขียน

เปนเสนทางการตัดสินใจ เหมือนก่ิงกานสาขาของตนไม เขน ราก แสดงเง่ือนไขท่ี 1 สงผลตอการ

กระทําท่ี 1 และเง่ือนไขท่ี 2 สงผลตอการกระทําท่ี 2 ดังภาพท่ี ดังภาพท่ี 8.2

ภาพท่ี 8.2 แสดงการเขียนตนไมแสดงการตัดสินใจ

ตารางการตัดสินใจ ใชในลักษณะของการปฏิบัติตามแตละกรณีท่ีเกิดข้ึนในระบบ โดยตารางจะ

ถูกแบงออกเปน 4 สวน คือ สวนบนซายเปนสวนท่ีอธิบายเง่ือนไข สวนบนขวาเปนสวนท่ีอธิบายเปนกฏ

สวนลางซายเปนสวนท่ีอธิบายกิจกรรมท่ีเกิดข้ึน และสวนลางขวาเปนสวนท่ีอธิบายการกระทํา ดังภาพท่ี

8.3

เง่ือนไข กฏ

กิจกรรม การกระทํา

ภาพท่ี 8.3 แสดงการเขียนตารางการตัดสินใจ

ระบบการ

ลงทะเบียนผา่น

อินเตอร์เน็ต นกัศึกษา

เจา้หนา้ท่ีทะเบียน

อาจารย ์

ขอ้มูลนกัศึกษา

ขอ้มูลการลงทะเบียน ขอ้มูลรายวชิา

ขอ้มูลอาจารย ์

ขอ้มูลหลกัสูตร ขอ้มูลการลงทะเบียน

ราก

เง่ือนไข 1


การกระทําท่ี 1

การกระทําท่ี 2

91

ภาษาเชิงโครงสราง เปนอีกวิธีหนึ่งท่ีใชภาษาอังกฤกษอธิบายข้ันตอนการทํางานของระบบ

ในการประมวลผล ดังภาพท่ี 8.4

ภาพท่ี 8.4 แสดงการเขียนภาษาเชิงโครงสราง

แผนภาพยูสเคส เปนแผนภาพท่ีแสดงภาพรวมของวิธีการทํางานท้ังหมดของระบบ รวมถึงผูท่ี

เก่ียวของในการทํางานสวนตางๆ ของระบบดวย สัญลักษณท่ีใชในการเขียนยูสเคส คือ สัญลักษณ

ยูสเคส สัญลักษณแสดงความสัมพันธ สัญลักษณแอคเตอร จะอธิบายดังนี้

สัญลักษณยูสเคส จะเขียนแทนโดยใชสัญลักษณรูปวงรี ซ่ึงแทนกิจกรรมท่ีเกิดข้ึน หรือวิธีการ

ทํางานตางๆ ท่ีมีอยูในระบบ เชน การจองตั๋ว การจายบิล เปนตน

สัญลักษณแสดงความสัมพันธ จะเขียนแทนโดยใชสัญลักษณลูกศร หรือเสนตรงเพียงเสนเดียว

หรือลูกศรแบบหัวสามเหลี่ยม เพ่ือแสดงถึงทิศทางของความสัมพันธท่ีสงระหวางยูสเคสและแอคเตอร

เพ่ือเปนการขยายใหเห็นถึงความเก่ียวของกันระหวางยูสเคสและแอคเตอร

สัญลักษณแอคเตอร จะเขียนแทนโดยใชสัญลักษณรูปคน เพ่ือแสดงตัวแทนท่ีอยูภายนอกระบบท่ี

ตองการแลกเปลี่ยน หรือสงขอมูลใหกับระบบ โดยท่ีแอคเตอรนั้นสามารถเปนไดท้ังระบบ คนและ

โปรแกรม ดังตารางท่ี 8.3

ตารางท่ี 8.3 ตารางแสดงสัญลักษณท่ีใชในการเขียนแผนภาพยูสเคส


สัญลักษณยูสเคส

การจองตั๋ว


การกระทํา 1


การกระทํา 2

.

.

.

เง่ือนไข N

การกระทํา N

92


สัญลักษณแสดงความสัมพันธ

สัญลักษณแอคเตอร

แผนภาพคลาส เปนแผนภาพท่ีแสดงโครงสรางของระบบ ซ่ึงประกอบดวย ความสัมพันธ

ระหวางคลาสตางๆ ในระบบ เพ่ือแสดงโครงสรางในระบบประกอบดวยคลาสอะไรบาง สัญลักษณท่ีสําคัญ

คือ สัญลักษณคลาสและสัญลักษณความสัมพันธ อธิบายดังนี้

สัญลักษณคลาส มาตรฐานยูเอ็มแอลเขียนแทนสัญลักษณคลาสดวยสีเหลี่ยม โดยแบงสี่เหลี่ยมนั้น

ออกเปน 3 สวน คือ ชื่อคลาส ลักษณะประจําคลาสหรืออ็อบเจกต และการปฏิบัติของคลาส

เพ่ือแสดงใหเห็นลักษณะของคลาสนั้น

สัญลักษณความสัมพันธ เขียนแทนดวยการใชสัญลักษณหัวลูกศรเปนสามเหลี่ยม เปนการแสดง

ความสัมพันธแบบรับทอดท่ีแสดงใหเห็นลักษณะของรูปแบบท่ัวไป สัมพันธกับรูปแบบเฉพาะ หรือลูกศรท่ี

มีหัวลูกศรเปนรูปขาวหลามตัด เปนการแสดงใหเห็นความสัมพันธแบบรวบรวมระหวางคลาสท้ังหมด และ

แบบไมมีหัวลูกศรเปนการแสดงความสัมพันธแบบเก่ียวเนื่องระหวางอ็อบเจกต และคลาสในทุกดานท่ีไมมี

การสืบทอด ดังตารางท่ี 8.4

ใชกรณีเปนผูถูกกระทํา

และผูกระทํา

ใชกรณีสงขอมูลทิศทาง

เดียว

<< use >>

<< extend >>

จอง

พนักงานจองตั๋ว

93

ตารางท่ี 8.4 ตารางแสดงสัญลักษณท่ีใชในการเขียนแผนภาพคลาส


คลาส

ชื่อคลาส

ลักษณะประจํา

การปฏิบัติ

ชื่อภาพยนตร

โรงหนังท่ีเขาฉาย

เวลา/รอบท่ีเขาฉาล

เพ่ิมชื่อ ()

ความสัมพันธ

แผนภาพแสดงสถานะ สาํหรับการเขียนแผนภาพสถานะเพ่ืออธิบายการปฏิบัติหรือพฤติกรรม

ของอ็อบเจกตตางๆ ในระบบวามีอะไรบาง มีการเปลี่ยนสถานะเม่ือเกิดเหตุการณบางอยางข้ึน สัญลักษณ

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

คือ

สวนท่ี 1 คือ สถานะ ใชระบุสถานะของอ็อบเจกต เชน ชําระเงินแลว ยังไมชําระเงิน เปนตน

สวนท่ี 2 คือ ตัวแปรท่ีมีในสถานะ เปนการระบุตัวแปรท่ีมีผลตอการเปลี่ยนสถานะ

สวนท่ี 3 คือ เหตุการณ/คําอธิบายกิจกรรม คือ เปนการระบุเหตุการณ ข้ึนในสถานะหรือ

คําอธิบายกิจกรรมท่ีเกิดข้ึน ดังภาพท่ี 8.5

ความสัมพันธแบบ

รับทอด


รวบรวม


เก่ียวเนื่อง

94

ภาพท่ี 8.5 แสดงสถานะของอ็อบเจกต

ตัวอยางการสรางแผนภาพแสดงสถานะของการจองตั๋วภาพยนตร ซ่ึงจะแบงออกเปน 2 สถานะ

คือสถานะท่ียังไมไดมีการชําระคาตั๋วภาพยนตร และเม่ือมีการชําระคาตั๋วภาพยนตร สถานะท่ีจะเกิดตอไป

คือ ชําระเงินแลว จากนั้นทําการออกตั๋วภาพยนตร ดังภาพท่ี 8.6

ภาพท่ี 8.6 แสดงการสรางแผนภาพแสดงสถานะของการจองตั๋วภาพยนตร

การเปรียบเทียบแผนภาพการไหลของขอมูลกับแผนภาพยูสเคส

ในสวนนี้จะขออธิยายถึงรูปแบบการเขียนแผนภาพการไหลของขอมูลเม่ือเปรียบเทียบกับ

แผนภาพยูสเคส ดังตอไปนี้

สวนของการประมวลผล เปนการเขียนสัญลักษณแทนการประมวลผล ซ่ึงเปนการเปลี่ยนแปลง

ขอมูลจากรูปแบบหนึ่งไปยังรูปแบบหนึ่ง และสัญลักษณแทนกิจกรรมท่ีเกิดข้ึน หรือฟงกชันตางๆ ท่ีมีใน

ระบบ ดังภาพท่ี 8.7

การประมวลผลขอมูล

ยูสเคส

ภาพท่ี 8.7 แสดงสัญลักษณแทนการประมวลผลเปรียบเทียบกับยูสเคส

ชําระเงินแลว

ยังไมชําระเงิน จองต๋ัวภาพยนตร

ชําระคาต๋ัวภาพยนตร ออกต๋ัวภาพยนตร

สถานะ

ตัวแปรที่มีผลตอการเปล่ียน

เหตุการณ/คําอธบิายกิจกรรม

95

สิ่งท่ีมีอยูนอกระบบ คือ คน หนวยงานภายในองคกร หนวยงานภายนอกองคกร หรือระบบ

สารสนเทศอ่ืนๆ ท่ีเปนสวนใหขอมูลหรือรับขอมูล เชน ลูกคา นักเรียน นักศึกษา เปนตน และแอคเตอร

คือตัวแทนสิ่งท่ีอยูภายนอกระบบ ซ่ึงมีสวนเก่ียวของกับระบบท้ังเปนผูกระทําใหเกิดยูสเคส และเปน

ผูถูกกระทําจากยูสเคส ดังภาพท่ี 8.8

สิ่งท่ีมีอยูนอกระบบ

แอคเตอร

ภาพท่ี 8.8 แสดงสัญลักษณแทนสิ่งท่ีมีอยูนอกระบบเปรียบเทียบกับแอคเตอร

การไหลของขอมูล คือ การแสดงเสนทางการไหลของขอมูลจากสวนหนึ่งไปยังอีกสวนหนึ่งของ

ระบบ และสัญลักษณแทนความสัมพันธ คือการแสดงใหเห็นการเปนผูกระทําใหเกิดยูสเคสนั้น หรือผูรับ

ผลลัพธจากยูสเคสนั้น หรือกรณีท่ียูสเคสนั้นมีการขยายใหเห็นยูสเคสยอยหรือยูสเคสนั้นมีการใชยูสเคสอ่ืน

ประกอบ ดังภาพท่ี 8.9

สิ่งท่ีมีอยูนอกระบบ

สัญลักษณแสดงความสัมพันธ

ภาพท่ี 8.9 แสดงสัญลักษณแทนสิ่งท่ีมีอยูนอกระบบเปรียบเทียบกับสัญลักษณแสดงความสัมพันธ

96

การเปรียบเทียบแผนภาพการไหลของขอมูลกับคลาส

ในสวนนี้จะขออธิยายถึงรูปแบบการเขียนแผนภาพการไหลของขอมูลเม่ือเปรียบเทียบกับแผน

คลาส ดังตอไปนี้

สวนการจัดเก็บขอมูล เปนสวนท่ีแทนสัญลักษณชื่อของแฟมขอมูลท่ีเก็บขอมูล เชน ขอมูล

อาจารย ขอมูลนักเรียน ขอมูลการลงทะเบียนเรียน เปนตน และสวนของการเก็บขอมูลของอ็อบเจกต

สําหรับใชในแผนภาพคลาส เปนสวนแสดงลักษณะประจําของอ็อบเจกตซ่ึงใชในการเก็บขอมูลตางๆ


สวนการจัดเก็บขอมูล

การเก็บขอมูลของอ็อบเจกต

ภาพท่ี 8.10 แสดงสัญลักษณแทนสวนการจัดเก็บขอมูลเปรียบเทียบกับการเก็บขอมูลของอ็อบเจกต

การประมวลผลขอมูล ซ่ึงเปนการเปลี่ยนแปลงขอมูลจากรูปแบบหนึ่งไปยังรูปแบบหนึ่ง และสวน

การปฏิบัตงานของอ็อบเจกต ใชในแผนภาพคลาสเปนสวนท่ีแสดงใหเห็นวาอ็อบเจกตนั้น มีฟงกชันการ

ทํางานหรือปฏิบัติงานใดบางในระบบ ดังภาพท่ี 8.11

การประมวลผลขอมูล

สวนการปฏิบัตงานของอ็อบเจกต

ภาพท่ี 8.11 แสดงสัญลักษณแทนการประมวลผลขอมูลเปรียบเทียบกับสวนการปฏิบัตงานของอ็อบเจกต

เสนทางการไหลของขอมูล เปนการแสดงเสนทางการไหลของขอมูล จากสวนหนึ่งไปยังอีกสวน

หนึ่งของระบบ และสัญลักษณแสดงความสัมพันธระหวางคลาสซ่ึงมีไดหลายกรณี คือ 1) แสดง

ความสัมพันธของการรับทอด 2) แสดงความสัมพันธการรวม 3) แสดงความสัมพันธท่ัวไป และใน

การแสดงความสัมพันธนั้นยังสามารถแสดงถึงความสัมพันธแบบหลายตอหลาย หนึ่งตอหนึ่ง หรือหนึ่ง

ตอหลาย โดยเขียนขอความกํากับในความสัมพันธไดอีกดวย ดังภาพท่ี 8.12

97

เสนทางการไหลของขอมูล

สัญลักษณแสดงความสัมพันธระหวางคลาส

ภาพท่ี 8.12 แสดงสัญลักษณแทนเสนทางการไหลของขอมูลเปรียบเทียบกับสัญลักษณแสดงความสัมพันธ

ระหวางคลาส

บทสรุป

การเขียนแผนภาพและการอธิบายระบบนั้น เพ่ือชวยในการทําความเขาใจกับระบบท่ีมีความ

ซับซอนสามารถใชแผนภาพการไหลของขอมูลในการวิเคราะหระบบเชิงโครงสรางแผนผังตนไมและตาราง

การตัดสินใจ เปนตน และการอธิบายแผนภาพเชิงวัตถุ สามารถใชแผนภาพยูสเคส แผนภาพคลาส

เปนตน ในสวนของการเปรียบเทียบสัญลักษณการใชงานคือการประมวลผลขอมูลกับยูสเคส คือสิ่งท่ีมีอยู

นอกระบบกับแอคเตอร สําหรับการเขียนอธิบายการไหลของขอมูลกับสัญลักษณแสดงความสัมพันธ สวน

ท่ีแตกตางกันคือ สัญลักษณแสดงความสัมพันธของการวิเคราะหระบบและออกแบบระบบเชิงอ็อบเจกต ท่ี

นอกจะใชในการสงขอมูลขาวสารแลว ยังสามารถแสดงใหเห็นการใชคลาสรวมกันในระบบ นอกจากนี ้

การเขียนอธิบายการประมวลผลนั้นยังขยายใหเห็นการทํางานของเคสยอยๆ ท่ีมีในระบบอีกดวย สําหรับ

สวนของแผนภาพแสดงการไหลของขอมูลและแผนภาพคลาสนั้น เปนสวนจัดเก็บขอมูล ไฟลขอมูลกับ

ลักษณะประจําของอ็อบเจกตท่ีสามารถแสดงความสัมพันธในรูปแบบท่ีลงรายละเอียดมากข้ึน เชน

การแสดงใหเห็นการรับทอด การแสดงใหเห็นการรวมหรือความสัมพันธแบบท่ัวไปอีกดวย


รับทอด


รวบรวม


เก่ียวเนื่อง

98


1. จงอธิบายประโยชนของการเขียนแผนภาพการไหลของขอมูล

2. จงอธิบายการเขียนตนไมแสดงการตัดสินใจ

3. จงอธิบายการเขียนสัญลักษณแผนภาพการไหลของขอมูล

4. จงอธิบายการเขียนสัญลักษณแผนภาพคอนเท็กซ

5. จงอธิบายประโยชนของเครื่องมือในการชวยอธิบายการะประมวลผล

6. จงอธิบายการเขียนสัญลักษณยูสเคส

7. จงอธิบายการเขียนสัญลักษณแผนภาคลาส

8. จงอธิบายการเขียนสัญลักษณแผนภาพสถานะ

9. จงอธิบายการเปรียบเทียบแผนภาพการไหลของขอมูลกับแผนภาพยูสเคส

10. จงอธิบายการเปรียบเทียบแผนภาพการไหลของขอมูลกับคลาส

99

อางอิง












(มหาชน).








what-cmmi.








Company.




100



Leffingwell Dean and Widring Don. 2004. “Manageing Software Requirements: A Use

Case Approach”. 2nd edition.,Massachusetts : Addison-wesles Professional.


101



1. การสรางแบบจําลองการวิเคราะห

2. การสรางกระบวนการเชิงวัตถุ

3. วิธีการหาความสัมพันธของคลาสดวยโมด


1. นักศึกษาสามารถอธิบายความหมายแบบจําลองการวิเคราะห

2. อธิบายการสรางกระบวนการเชิงวัตถุ

3. อธิบายวิธีการหาความสัมพันธของคลาสดวยโหมด



1.1 วิธีการสอนแบบบรรยาย เริ่มจากอธิบายการสรางแบบจําลองการวิเคราะห การ

สรางกระบวนการเชิงวัตถุ และวิธีการหาความสัมพันธของคลาสดวยโมด




2.1 แสดงตัวอยางวิธีการหาความสัมพันธของคลาสดวยโมด

2.2 แบงกลุมอภิปรายเรื่องข้ันตอนการจําลองการวิเคราะหเปนอยางไร






102





103

บทท่ี 9

แบบจําลองการวิเคราะห

ในบทนี้กลาวถึงการสรางแบบจําลองการวิเคราะหเพ่ือใหนักวิศวกรซอฟตแวรเลือกใชใหเหมาะสม

กับงานท่ีพัฒนา การสรางแบบจําลองการวิเคราะหเริ่มจากการสรางเอ็นทิตี รีเลชัน ไดอะแกรม ซ่ึง

ประกอบดวยสวนท่ีสําคัญ เชน ดาตา ไดเร็คทอรี ขอมูลวัตถุ กระแสภาพการไหลของขอมูล พรอมท้ัง

ยกตัวอยางประกอบความเขาใจ ในสวนของวิธีการสรางกระบวนการเชิงวัตถุ ไดอธิบายถึงหลักการของ

การออกแบบเชิงวัตถุ การออกแบบคอมโพเนนทแบบคลาส การออกแบบยูสเคสไดอะแกรม การเชื่อมโยง

ความสัมพันธ การออกแบบซีเควนซไดอะแกรม และวิธีหาความสัมพันธของคลาสดวยคลาสโมด ซ่ึงเปน

วิธีการคํานวนหาความสัมพันธของคลาสและวัตถุอยางเหมาะสม เพ่ือใหนักวิศวกรซอฟตแวรออกแบบ

ระบบไดอยางมีคุณภาพ

การสรางแบบจําลองการวิเคราะห

เม่ือนักวิศวกรซอฟตแวรไดรวบรวมขอมูลท่ีสําคัญ เชน เอกสารรายงานความตองการของระบบ

เอกสารประมาณรายละเอียดของงานพัฒนาซอฟตแวร และกําหนดขอตกลงรวมถึงขอบเขตของการ

พัฒนาซอฟตแวร ท้ังหมดไดนํามาสราง เอ็นทิตี รีเลชัน ไดอะแกรม (entity relation diagram :ERD) ซ่ึง

มีรายละเอียดท่ีสําคัญดังนี้

1. ดาตา ไดเร็คทอรี (Data Directory) เปนการใหความหมายขอมูลท่ีจําเปนในระบบ ซ่ึงมี

ความสัมพันธกับสวนตางท้ังระบบ ผูพัฒนาซอฟตแวรจะใหนิยามของขอมูลรวมท้ังชนิดของขอมูลดวย

การอธิบายในสวนของสเปคการทํางานของซอฟตแวร (Process Spectcifcation) ใชการเขียนแผนภาพ

การไหลของขอมูล (Data Flow Diagram) สวนของการควบคุม (Control Spectcifcation) ใชการเขียน

แผนภาพสถานะการถายโอนขอมูล (State-Transition Diagram) และสวนอธิบายขอมูลและวัตุ (Data

Object Description) ใชการเขียนแผนภาพความสัมพันธระหวาง เอ็นทิตี ไดอะแกรม (Entity

Relationship Diagram) ดังภาพท่ี 9.1

104

ภาพท่ี 9.1 แสดงรายละเอียดดาตา ไดเร็คทอรี

ท่ีมา: Roger S. Pressman. (2005). Software Engineering. (6th ed.). Mc-Graw-Hill.

2. ขอมูลวัตถุ (Data Object) แอตทริบิวส (Attribute) และความสัมพันธ (Relationship) ท้ัง

สามสวนนี้มีสวนท่ีสําคัญสําหรับการทําความเขาใจขอมูลเพ่ือพัฒนาซอฟตแวร ดังจะอธิบายตอไปนี้

วัตถุขอมูล เปนการแทนขาวสารท่ีประกอบกันข้ึนท่ีซอฟตแวรจะตองเขาใจคําวา ขาวสารท่ี

ประกอบกัน (Composite Information) เราหมายถึงบางสิ่งบางอยางท่ีมีคุณสมบัติแตกตางกันหรือมี

แอตทริบิ วสแตกตางกัน ดั งนั้น ความกวางซ่ึงมีค าเดียวอาจจะไม ใชวัต ถุขอมูล ท่ีดีนักแต มี มิติ

(Dimensions) ท่ีมีท้ังความสูง ความกวาง และความลึก อาจจะถูกนิยามเปนวัตถุได เชน คน และรถยนต

แอตทริบิวสขอมูล นิยามคุณสมบัติของวัตถุขอมูล แอตทริบิวสขอมูลอาจจะอยูในหนึ่งในสาม

รูปแบบตอไปนี้เปนชื่อของกรณีตัวอยาง (Instance) ของวัตถุขอมูล อธิบายกรณีตัวอยางนั้น อางอิงไปถึง

กรณีตัวอยางอ่ืนในตารางอ่ืนๆ แอตทริบิวสขอมูล (Data Attributes) นอกจากนี้เราจะตองนิยาม

แอตทริบิวสใดแอตทริบิวสหนึ่งใหเปนตัวบงชี้ (Identifier) นั่นคือ แอตทริบิวสบงชี้จะกลายเปนกุญแจ

(Key) เม่ือเราตองการคนหากรณีตัวอยางของวัตถุขอมูล ในหลายกรณีคาของตัวบงชี้จะตองเปนเอกลักษณ

แมวาบางครั้งอาจจะไมจําเปน เชน ชื่อ ท่ีอยู อายุ เลขท่ีใบขับข่ี

ความสัมพันธ คือคูของวัตถุความสัมพันธท่ีมีความสัมพันธเก่ียวของกัน เชน คนเปนเจาของ

รถยนต ดังภาพท่ี 9.2

105

ภาพท่ี 9.2 แสดงรายละเอียดขอมูลวัตถุ แอตทริบิวสและความสัมพันธ


3. กระแสภาพการไหลของขอมูล (Data Flow Diagram) ใชแสดงอธิบายการทํางานของระบบ

โดยเนนท่ีขอมูลและความสัมพันธกันในระบบ เพ่ือเปนประโยชนในการสราง การบํารุงรักษาและทําความ

เขาใจลําดับเหตุการณท่ีจะเกิดข้ึนในระบบ ยกตัวอยาง ระบบหนึ่งแบงการทํางานออกเปน 3 ระดับ โดย

ระดับแรกจะแสดงในโหนด F ซ่ึงมีการนําเขาขอมูลจาก A และสงขอมูลออกดวย B ในระดับท่ีสองจะ

แสดงรายละเอียดในการทํางานยอยในโหลด F คือ f1, f2, f3, f4, f5, f6 และ f7 ตามลําดับ ในระดับท่ีสาม

จะแสดงการทํางานยอยของโหลด f4 คือ f41, f42, f43, f44 และ f45 ตามลําดับ ดังภาพท่ี 8.3

ภาพท่ี 9.3 แสดงรายละเอียดกระแสภาพการไหลของขอมูล


106

ตัวอยางการเขียนกระแสภาพการไหลของขอมูลระบบเรียลไทม (Real Time) มีข้ันตอนดังนี้ สวน

ของการทํางานหลักการตรวจจับและปรับแตงอุณหภูมิ (Monitor and Adjust Temperature) แบงสวน

นําเขาขอมูลเพ่ือประมวลผลออกเปน 2 สวน คือ 1) สวนตรวจจับ (Monitored Temperature) ซ่ึงมี

ขอมูลเขาอยางตอเนื่อง 2) การต้ังคาอุณหภูมิ (Temperature Set Point) เม่ือนําเขาขอมูลท้ังสองระบบ

จะทําการประมวลผล สงขอมูลออก คือคาของอุณหภูมิปจจุบัน ดังภาพท่ี 9.4

ภาพท่ี 9.4 แสดงตัวอยางการเขียนกระแสภาพการไหลของขอมูลระบบเรียลไทม


ตัวอยางการเขียนกระแสภาพการไหลของขอมูลในการทํางานระดับยอยของระบบควบคุม

การเคลื่อนท่ีของหุนยน เริ่มจากสถานะตางท่ีจําเปนตองมีในระบบการควบคุมการเคลื่อนท่ี (Status of

each fixture) โดยระบบทําการโหลดขอมูลเก็บใวในสวนความจําชั่วคราว (Parts status buffer) และนํา

ขอมูลเขาชนิดบิต สตริง (Bit string) สงเขาประมวลผลระบบยอย การติดตามและปฏิบัติการ (Monitor

fixture & operator interface) สิ่งท่ีไดจากการประมวลผลแบงเปน 2 สถานะ คือ 1) สถานะเริ่ม หรือ

เวนวางระยะหนึ่ง (Start/stop flag) นําเขาขอมูลตอไปยัง ระบบยอยเริ่มตนควบคุมหุนยน (Robot

iniation control) โดยตั้งคาเตือนเพ่ือการเคลือนท่ีตอไป (Movement alarm) และสั่งใหเคลื่อนท่ี

(Process Active) 2) สถานะดําเนินการตอ ถูกเชื่อมตอดวยชุดคําสังของหุนยนต (Robot command

file) ดังนั้นจึงทําการประมวลผลจากการเคลือนท่ีกอนหนานี้ (Robot movement record) ตําแหนง

ปจจุบัน และการเคลื่อนท่ีตําแหนงใหม (Position commands) ดังภาพท่ี 9.5

107

ภาพท่ี 9.5 ตัวอยางการเขียนกระแสภาพการไหลของขอมูลในการทํางานระดับยอยของระบบควบคุม

การเคลื่อนท่ีของหุนยนต


การสรางกระบวนการเชิงวัตถ ุ

หลักการของการออกแบบเชิงวัตถุนั้น เนนไปท่ีกระบวนการ มองสิ่งท่ีสนใจ เรียกวา วัตถุ การ

ทํางานจะถูกนําเอาขอมูลและกระบวนการมารวมกัน รวมถึงโครงสราง พฤติกรรม สถานะ การทํางาน

รวมกันของวัตถุตางๆ นักวิศวกรซอฟตแวรจะทําหนาท่ีในการออกแบบสวนใดๆ ของระบบท่ีเปนโมดูล

เรียกใชงานและแทนท่ีได ท่ีเรียกวา คอมโพเนนท (Component) ในสวนของการออกแบบจึงจําเปนตอง

ใชเครื่องมือชวยเพ่ือใหงายกับการจําลองซอฟตแวรในมุมมองตางๆ ผูพัฒนาระบบจึงควรทําคามเขาใจกับ

แนวคิดเชิงวัตถุ ดังจะอธิบายดังนี้

แอตทริบิวส คือการรวบรวมคาของขอมูลท่ีใชอธิบายคลาส

คลาส คือรวบรวมขอมูลและกระบวนการท่ีจัดการกับขอมูลภายในคลาส คลาสเปนคําอธิบาย

โดยท่ัวไปท่ีอธิบายวุตถุท่ีมีพฤติกรรมใกลเคียงกัน

การดําเนินการ หรือ โอเปอรเรชัน บางครั้งเรียกวาวิธีการ บางเรียกวาบริการ โอเปอรเรชันนี้ใช

เปนตัวแทนของพฤติกรรมของคลาสหนึ่ง

108

ซับคลาส เปนกรณีเฉพาะของซูปเปอรคลาส โดยสามารถถายทอดคุณสมบัติท้ังทางแอตทริบิวส

และโอเปอรเรชันจากซูปเปอรคลาสได

ซูปเปอรคลาส คือคลาสฐานเปนกรณีท่ัวไปของชุดคลาสท่ีมีความเก่ียวของกัน

การออกแบบคอมโพเนนทแบบคลาส เปนการออกแบบระบบโดยใชขอมูลจากแบบจําลองการ

วิเคราะหระบบ เปนการแสดงรายละเอียดของแบบจําลองสถาปตยกรรม การออกแบบคอมโพเนนทจะ

เนนอธิบายรายละเอียดของคลาส แอตทริบิวสตัวปฏิบัติการ และสวนตอประสาน โดยมีหลักการออกแบบ

พ้ืนฐาน ดังนี้

1. หลักการเปดและปด นักวิศวกรซอฟตแวรจะกําหนดคอมโพเนนทในลักษณะอนุญาตใหขยาย

ใหญ โดยไมจําเปนตองแกไขโคดโปรแกรม กลาวคือการสรางคลาสตัวกลางระหวางหนาท่ีการทํางานกับ

คลาสออกแบบ

2. หลักการแทนท่ีลิสคอฟ หลักการนี้นําเสนอโดย Barbara Liskov มีหลักการวาคอมโพเนนทท่ี

ใชงานคลาสมูลฐานควรท่ีจะดําเนินตอไปไดตามปกติ ถาหากคลาสถูกสงใหคอมโพเนนทนั้นแทน หลักการ

นี้ตองการใหคลาสลูกทําตามขอกําหนดของคลาสแมกอน ถากรณีเปนจริงจึงทําตามขอกําหนดท่ีรองขอใน

ภายหลัง

3. หลักการความผกผันของการข้ึนแกกัน หลักการนี้อาศัยหลักการเปดและปด นักวิศวกร

ซอฟตแวรจะทําการออกแบบขยายคอมโพเนนทไดโดยไมสรางความซับซอนจนเกินไป ยิ่งมีคอมโพเนนทท่ี

ข้ึนแกกันมากยิ่งทําใหการทํางานซับซอนข้ึน

4. หลักการแยกสวนตอประสาน โดยท่ัวไปแลวการออกแบบคอมโพเนนทจะใหบริการกับคลาส

หลายคลาส แนะนําใหแยกสวนตอประสานไวสําหรับคลาสแตละตัว และควรจัดกลุม จัดระเบียบของสวน

ตอประสานใหเหมาะสมเพ่ืองายกับการออกแบบ

5. หลักการความเทากันของรีรีสและรียูส เปนวิธีการนํากลับมาใชใหม มักจะเกิดเหตุการณ

การณ นําเอาเอนทิต้ีกลับมาใชใหมอยูเสมอ การออกแบบแนะนําใหปรับปรุงเปนเวอรชันเปนสิ่งท่ีควรทํา

มากกวาการแยกคลาส ซ่ึงในระยะยาวสามารถบํารุงรักษาระบบไดดีกวา

การออกแบบยูสเคสไดอะแกรม ยูสเคสไดอะแกรม เปนสัญลักษณท่ีแสดงความสัมพันธในระบบ

เชนหนาท่ีท่ีระบบตองกระทําใชสัญลักษณรูปวงรี พรอมท้ังเขียนชื่อ Use Case ซ่ึงตองใชคํากริยาหรือ

กริยาวลีก็ได ตัวอยาง ภาพท่ี 9.6

ภาพท่ี 9.6 แสดงสัญลักษณยูสเคสไดอะแกรม

จองทัวร

109

แอคเตอร (Actor) หมายถึงผูเก่ียวของกับระบบ ท้ังท่ีเปนหลักและสวนรอง และท่ีเปนมนุษย ใน

ท่ีนี้จะใช สัญลักษณรูปคน พรอมท้ังเขียนชื่อแอคเตอร ไวดานลางของสัญลักษณดวย แตหากเปนแอคเตอร

ท่ีไมใชมนุษยจะเปนรูปสี่เหลี่ยม ดังภาพท่ี 9.7

ภาพท่ี 9.7 แสดงสัญลักษณแอคเตอร

ระบบ เปนเสนแบงขอบเขตระหวางระบบกับผูกระทําตอระบบ ใชรูปสี่เหลี่ยมเปนสัญลักษณ

พรอมท้ังเขียนชื่อระบบไวดานใน ดังภาพท่ี 9.8

ภาพท่ี 9.8 แสดงสัญลักษณระบบ

การออกแบบเชื่อมโยงความสัมพันธ เสน ท่ีลากเชื่อมตอระหวางแอคเตอรกับระบบท่ีมี

ความสัมพันธกันในระบบ โดยการเชื่อมระหวางแอคเตอรกับระบบจะไมมีหัวลูกศร และระหวางระบบ

ดวยกันจะมีหัวลูกศรและขอความแสดง ดังแสดงในตัวอยาง ภาพท่ี 9.9

ภาพท่ี 9.9 แสดงสัญลักษณแสดงการเชื่อมโยงความสัมพันธ

ตัวอยางระบบควบคุมความปลอดภัยของบาน เจาของบาน (Homeowner) มีความสัมพันธ

เชื่อมโยงดวยกันสองสวน คือ สวนท่ีติดตอ (Interacts) และสวนปรับแตงองคประกอบ (Configures) ดัง

ในภาพ (a) และภาพ (b) คือภาพท่ีแสดงรายละเอียกระบบยอย เพ่ือใหเห็นภาพรวมยิ่งข้ึน ดังภาพท่ี 9.10

Actor - Use Case Use Case – Use Case

System

<<Actor>>

<<Actor Name>>

110

(a)

(b)

ภาพท่ี 9.10 แสดงภาพยูสเคส (a) และ (b) ระบบควบคุมความปลอดภยัของบาน


การออกแบบซีเควนซไดอะแกรม (Sequence Diagram) เปนการเขียนลําดับเหตุการณของงาน

ท่ีเกิดข้ึน เพ่ือแสดงถึงการทํางานของแตละสวนท่ีเชื่องโยงกัน ตัวอยางการเขียนซีเควนซไดอะแกรม

สําหรับระบบรักษาความปลอดภัยของบาน ลูกศรแสดงถึงเหตุการณซ่ึงไดมาจากระบบ เพ่ือเปนการระบุ

วาเหตุการณนั้นสงผลตอพฤติกรรมระหวางวัตถุระบบรักษาความปลอดภัยของบาน เวลาจะแสดงดวย

เสนประในแนวตั้ง โดยเวลาท่ีมีมากข้ึนสามารถอานไดจากทิศทางลง วิธีการอานแผนภาพซีเควนซ

ไดอะแกรมนี้จะทราบถึงเหตุการณท้ังหมดกอใหเกิดการเคลื่อนยายสถานะระหวางวัตถุในระบบ ซ่ึงจะ

ทํางานรวมเปนชุดแตละเหตุการณ ดังภาพท่ี 9.11

ภาพท่ี 9.11 ภาพแสดงการเขียนซีเควนซไดอะแกรมสําหรับระบบรักษาความปลอดภัยของบาน


111

วิธีการหาความสัมพันธของคลาสดวยโมด

ในการออกแบบโปรแกรมเชิงวัตถุนั้น การกําหนดคลาสและอ็อบเจ็กตเปนสิ่งท่ีสําคัญตอ

การออกแบบใหซอฟตแวรนั้นทํางานไดเต็มประสิทธิภาพ ในการกําหนดจํานวนวิธีการท่ีสืบทอดสามารถ

คํานวณไดดังนี้

Method inheritance factor (MIF) คือจํานวนของการถายทอดของคลาส ในการออกแบบ

โปรแกรมเชิงวัตถุ ท้ังท่ีเปนตัวดําเนินงานและแอตทริบิวส คํานวณไดจากสมการนี้

)(/)( iaii CMCMMIF ∑ ∑=

เม่ือ i แทนกรณีท่ีตองการหาคา มีคาตั้งแต 1 ถึง TC. โดย TC หมายถึงจํานวนท้ังหมดของคลาสท่ีเกิดข้ึน

)C(M)C(M)C(M iiidia +=

เม่ือ aM คือจํานวนของ Method ท้ังหมดท่ีมีความเก่ียวของกับ iC

dM คือจํานวนของ Method ท้ังหมดท่ีประกาศใชกับ iC

iM คือจํานวนของ Method ท้ังหมดท่ีมีการสืบทอดกับ iC

Couping factor (CF) เปนการคํานวณหาสวนท่ีเชื่อมโยงกันของท้ังคลาสและอ็อบเจ็กตใน

การออกแบบเชิงวัตถุ สามารถคํานวณไดจากสมการนี้

)TCTC/()]C,C(client_is[CF jiji −= ∑∑ 2

เม่ือ client_is =1 , if and only if คือคาความสัมพันธระหวางคลาส , sC CC ≠ คือคลาสในอ็อบเจ็กต

Polymorphism factor (PF) คือจํานวนของ Method ท่ีถูกประกาศใชในการสืบทอดของ

Method นั้น สามารถคํานวณไดจากสมการนี้

∑ ∑ ×= )]C(DC)C(M[/)C(MMIF iiniioi

112

เม่ือ 1=i ถึง TC และ

)C(M)C(M)C(M ioinid +=

เม่ือ )C(M in คือจํานวนของ Method ใหม

)C(M io คือจํานวนของ Method ท่ีถูกเขียนทับ

)C(DC i คือจํานวนของ Method ท่ีสืบทอดท้ังหมด

บทสรุป

วัตถุประสงคของการสรางแบบจําลองวิเคราะห เพ่ือใหนักวิศวกรซอฟตแวรไดรวบรวมขอมูลท่ี

สําคัญและสรางตัวแทนเปนสัญลักษณหลายรูปแบบท่ีสามารถอธิบายความตองการของซอฟตแวรใน

มุมมองของขอมูลขาวสาร หนาท่ีและพฤติกรรมเพ่ือใหบรรลุถึงวัตถุประสงคของการพัฒนาซอฟตแวร

เรียนรูวิธีการสรางกระบวนการเชิงวัตถุ การออกแบบสวนตางๆ ท่ีเปนแนวคิดเชิงวัตถุ เชน การออกแบบ

คอมโพเนนทแบบคลาส การออกแบบยูสเคสไดอะแกรม การออกแบบซีเควนไดอะแกรม และวิธีการหา

ความสัมพันธของคลาสดวยโมด เพ่ือใหการออกแบบคลาสและอ็อบเจ็กตมีความสัมพันธกันอยาง

พอเหมาะ


1. จงอธิบายวัตถุประสงคของการสรางแบบจําลองการวิเคราะห

2. จงอธิบายดาตา ไดเร็คทอรี่ หมายถึงอะไร

3. จงอธิบายกระแสภาพการไหลของขอมูล

4. จงอธิบายประโยชนของกระแสภาพการไหลของขอมูล

5. จงอธิบายแนวคิดวิธีการสรางกระบวนการเชิงวัตถุ

6. จงอธิบายการออกแบบคอมโพเนนทแบบคลาส

7. จงอธิบายการออกแบบยูสเคสไดอะแกรม

8. จงอธิบายการออกแบบซีเควนซไดอะแกรม

9. จงอธิบายประโยชนวิธีการหาความสัมพันธของคลาสดวยโมด

10. จงอธิบายและยกตัวอยาง แอตทริบิวส คลาส การดําเนินการ ซับคลาส และซูปเปอรคลาส

113

อางอิง












(มหาชน).








what-cmmi.







Ian Sommerville, (2010)."Software Engineering (9th Edition)", Addison-Wesley Publishing

Company.




http://www.dailymail.co.uk/sciencetech/article-2219188/Inside-Google-pictures-gives-look-8-vast-data-centres.html




114


Company.






Massachusetts,Addison-Wesley.



Boobh,G,Rumbaugh,J,and Jacobson,I. 1998. “The Unified Modeling Language User

Guide”, Massachusetts : Addison-wesles

115



1. บัญญัติในการออกแบบสวนตอประสานผูใชงาน

2. แบบจําลองการวิเคราะหและออกแบบสวนตอประสานผูใชงาน

3. ลักษณะการออกแบบสวนตอประสานผูใชงานท่ีดี

4. กระบวนการการออกแบบสวนตอประสานผูใชงาน

5. สิ่งท่ีตองคํานึงถึงเม่ือทําการออกแบบสวนตอประสานผูใชงาน

6. ตัวอยางการออกแบบสวนตอประสานผูใชงาน


1. นักศึกษาสามารถอธิบาย บัญญัติในการออกแบบสวนตอประสานผูใชงาน แบบจําลองการ

วิเคราะหและออกแบบสวนตอประสานผูใชงาน ลักษณะการออกแบบสวนตอประสานผูใชงานท่ีดี

กระบวนการการออกแบบสวนตอประสานผูใชงาน สิ่งท่ีตองคํานึงถึงเม่ือทําการออกแบบสวนตอประสาน

ผูใชงาน และตัวอยางการออกแบบสวนตอประสานผูใชงาน

2. นักศึกษาสามารถออกแบบสวนตอประสานผูใชงาน



1.1 วิธีการสอนแบบบรรยาย เริ่มจากอธิบาย บัญญัติในการออกแบบสวนตอประสาน

ผูใชงาน แบบจําลองการวิเคราะหและออกแบบสวนตอประสานผูใชงาน ลักษณะการออกแบบสวนตอ

ประสานผูใชงานท่ีดี กระบวนการการออกแบบสวนตอประสานผูใชงาน สิ่งท่ีตองคํานึงถึงเม่ือทําการ

ออกแบบสวนตอประสานผูใชงาน และตัวอยางการออกแบบสวนตอประสานผูใชงาน




2.1 แสดงตัวอยางตัวอยางการออกแบบสวนตอประสานผูใชงาน

2.2 แบงกลุมอภิปรายเรื่องสิ่งท่ีตองคํานึงถึงเม่ือทําการออกแบบสวนตอประสานผูใชงาน


116









117

บทท่ี 10

การออกแบบสวนตอประสานผูใชงาน

ในบทนี้จะกลาวถึงวิธีการออกแบบสวนผูใชงาน โดยมีสิ่งท่ีสําคัญบัญญัติในการออกแบบสวนตอ

ประสานผูใชงาน การสรางแบบจําลองวิเคราะหและออกแบบสวนประสานผูใชงานมีความสําคัญตอการ

พัฒนาซอฟตแวร เชน แบบจําลองผูใช กําหนดขอมูลท่ีแสดงลักษณะเฉพาะของผูใชงานระบบ แบบจําลอง

การออกแบบของท้ังระบบ แบบจําลองการอิมพลิเมนต นอกจากนี้ยังตองคํานึงถึงกระบวนการในการ

พัฒนาสวนตอประสานผูใชงาน ลักษณะการออกแบบสวนตอประสานผูใชงานท่ีดี กระบวนการการ

ออกแบบสวนตอประสานผูใชงาน สิ่งท่ีตองคํานึงถึงเม่ือทําการออกแบบสวนตอประสานผูใชงาน และ

ตัวอยางการออกแบบสวนตอประสานผูใชงาน

บัญญัติในการออกแบบสวนตอประสานผูใชงาน

สวนของการออกแบบสวนตอประสานผูใชงานนั้น จําเปนจะตองคํานึงถึงบัญญัติกฎ 3 ขอในการ

ออกแบบสวนตอประสานผูใชงาน คือ ใหผูใชเปนผูควบคุมการทํางาน ลดภาระการตองจดจําของผูใช และ

สรางสวนตอประสานผูใชงานอยางคงเสนคงวา ดังจะอธิบายตอดังนี้

1. ใหผูใชเปนผูควบคุมการทํางาน ลักษณะการกําหนดโหมดการโตตอบในลักษณะท่ีไมบังคับ

ผูใชโดยไมจําเปน หรือในทางท่ีดีผูใชไมตองการท่ีจะทําโหมดการโตตอบคือสถานะปจจุบันของสวนตอ

ประสานผูใชงาน ตัวอยางเชน เม่ือผูใชตองการตรวจสอบการสะกดคํา ถาผูใชเลือกเมนูตรวจสอบการ

สะกดคํา ซอฟตแวรจะไปอยูในโหมดการตรวจสอบการสะกดคํา ซ่ึงจะทําใหไมสามารถใชงานอ่ืนๆ ตอไป

ไดจนกวาการสะกดคําจะเสร็จสิ้น แตถาผูใชตองการพิมพงานตอไปพรอมๆ กัน ซอฟตแวรก็ควรจะใหผูใช

และออกจากโหมดไดโดยงาย

2. ลดภาระการตองจดจําของผูใช ลดความตองการใชหนวยความจําระยะสั้นของผูใชเม่ือผูใช

กําลังทํางานท่ีซับซอน ความตองการใชหนวยความจําระยะสั้นอาจมีมาก สวนตอประสานผูใชงานควรจะ

ออกแบบใหลดความจําเปนท่ีตองจดจําการกระทําและผลท่ีเพ่ิงมา โดยแสดงรองรอยของการกระทําท่ีผาน

มาโดยไมตองมารื้อฟนความจํา

3. สรางสวนตอประสานผูใชงานอยางคงเสนคงวา ชวยใหผูใชทราบวางานปจจุบันอยูภายใต

บริบทใดภายใตการโตตอบกับระบบผานลําดับชั้นอันซับซอนหลายหนาจอ ทําใหผูใชงานสับสนได จึง

จําเปนตองมีตัวบงชี้ เชน ชื่อหนาท่ีไอคอน สี ท่ีชวยใหผูใชงานทราบวา บริบทของงานปจจุบันคืออะไร มา

จากสวนงานใดและจะไปตอไดอยางไรบาง

118

แบบจําลองการวิเคราะหและออกแบบสวนตอประสานผูใชงาน

สําหรับนักวิศวกรซอฟตแวรนั้น มีหนาท่ีสรางแบบจําลองการวิเคราะหและออกแบบสวนตอ

ประสานผูใชงาน ท้ังนี้เพ่ือใหเหมาะสมกับผูใชงาน และภาพรวมของระบบ

1. แบบจําลองผูใช กําหนดขอมูลท่ีแสดงลักษณะเฉพาะของผูใชงานระบบ การออกแบบควร

เริ่มจากการทําความเขาใจผูใชงานดานตางๆ รวมถึง อายุ เพศ ความสามารถทางรางกาย การศึกษา

วัฒนธรรมเชื้อชาติ แรงจูงใจ เปาหมาย และบุคลิกภาพ นอกจากนี้ อาจแบงผูใชงานออกเปน

ผูเริ่มใชงาน ไมมีความรูในการใชงานระบบมากอน และมีความรูเก่ียวกับตัวระบบเพียงเล็กนอย

ผูใชงานปานกลางมีความรูพอควรเก่ียวกับระบบ แตยังใชงานไมคลองแคลว จําเปนตองไดรับความ

ชวยเหลือจากสวนตอประสานผูใชงาน

ผูใชงานบอย มีความรูดีมากในการใชงาน อันนําไปสูอาการผูใชระดับสูง คือบุคคลท่ีมองหา

ทางลัดและการกระทําแบบยอในการประสานกับระบบ

2. แบบจําลองการออกแบบของท้ังระบบ รวมเอาขอมูลสถาปตยกรรมสวนตอประสานผูใชงาน

และตัวแทนกระบวนการของซอฟตแวรเขาดวยกัน ขอกําหนดความตองการอาจมีเง่ือนไขท่ีชวยกําหนด

ผูใชงานระบบ แตสวนตอประสานผูใชงานมักเก่ียวของโดยตรงกับแบบจําลองการออกแบบ

3. แบบจําลองการอิมพลิเมนต รวมเอาการจัดระบบคอมพิวเตอร เชน หนาตาของสวนตอ

ประสานผูใชงาน เขากับการสนับสนุนของขอมูล เชน หนังสือคูมือไฟลชวยงานท่ีอธิบายความหมายและ

ไวยากรณของระบบ เม่ือแบบจําลองการอิมพลิเมนตกับแบบจําลองสภาพจิตของผูใชประสานเขากันไดดี

ผูใชงานจะรูสึกสบายกับการใชงาน และใชไดอยางมีประสิทธิภาพ เพ่ือใหบรรลุการเชื่อมตอนี้ แบบจําลอง

การออกแบบถูกตองพัฒนาใหรองรับขอมูลท่ีบรรจุในแบบจําลองสภาพจิตผูใช และแบบจําลองการอิมพลิ

เมนตตองแมนตรง ในการสะทอนภาพไวยากรณและความหมาย

119

ลักษณะการออกแบบสวนตอประสานผูใชงานที่ดี

ทีมงานผูท่ีพัฒนาระบบควรจะตองคํานึงถึงการใชงานของผูใชเปนสําคัญ โดยสามารถยึดหลักการ

ดังตอไปนี้

1. ไมบีบค้ันใหผูใชงานโตตอบกับระบบโดยไมมีความจําเปน การแกไขพฤติกรรมการใชงานใน

ระบบนั้นบางครั้งก็ไมจําเปนจะตองบังคับใหผูใชงานทําการยืนยันทุกครั้งไป ใหผูใชงานโตตอบกับระบบใน

สวนท่ีสําคัญจริง เชน ตองการลบ ตองการบันทึก

2. ออกแบบใหผูใชงานสามารถโตตอบกับระบบไดมากกวา 1 ชองทาง มีการกําหนดชองทาง

การใชงานทางคียบอรด เมาส หรืออุปกรณเชื่อมตออ่ืนๆ ท่ีเห็นวาจําเปน ตองคํานึงถึงการใชงานท่ี

เหมาะสมดวย

3. สามารถยกเลิกการทํางานและสลับการทํางานได โดยระบบจะมีสวนของการกูคืนขอมูล

กอนหนาใหโดยอัตโมมัติเม่ือผูใชงานทําการยกเลิกการทํางาน

4. จัดเตรียมเครื่องมือการสรางการทํางานพ้ืนฐานโดยอัตโนมัติ การทํางานมาตรฐานของระบบ

บางครั้ง เปนการสรางหรือเตรียมขอมูลพ้ืนฐานเอาใวสําหรับอํานวยความสะดวกใหกับผูใชอีกทางหนึ่งดวย

5. ไมควรท่ีจะใหระบบสั่งงานดวยการพิมพคําสั่ง (Command Line) ควรจะสรางเครื่องมือ

อัตโนมัติเพ่ือท่ีจะทําการเชื่อมตอกับระบบปฏิบัติการโดยไมใชการพิมพคําสั่ง

6. การทํางานตองกระทําตอวัตถุโดยตรง เชนผูใชงานสามารถท่ีจะแทรกไฟลภาพ ยอ ขยาย

ขนาดของไฟลภาพนั้นไดโดยตรง

กระบวนการการออกแบบสวนตอประสานผูใชงาน

กิจกรรมท่ีเกิดข้ึนนั้นมีลักษณะการทํางานวนซํ้า เพ่ือเปนการทบทวนรูปแบบท้ังผูพัฒนาและลูกคา

ใหเขาใจท่ีตรงกัน หากฝายหนึ่งฝายใดพบขอบกพรองจึงทําการแกไขปรับปรุงอยางเรงดวน เพ่ือการสง

มอบใหทันตอเวลาท่ีกําหนด กระบวนการการออกแบบสวนตอประสานผูใชงานโดยเริ่มจาก ทีมงาน

วิเคราะหความตองการของระบบ จะทําการสรางตนแบบ สงใหลูกคาและทีมงานชวยกันประเมิน เม่ือท้ัง

สองฝายเห็นตรงกัน จึงเริ่มทําเอกสารตนแบบ ระหวางกระบวนการนี้อาจจะใหลูกคาประเมินเปนระยะ

จากนั้นทําการสรางตนแบบใชงานโดยท่ีสามารถใชงานระบบนี้ไดจริง เม่ือใชงานระยะหนึ่งจึงทําตนแบบท่ี

ใชงานไดจริงถือเปนการสิ้นสุดการออกแบบสวนตอประสานผูใชงาน ดังภาพท่ี 10.1

120

ภาพท่ี 10.1 กระบวนการการออกแบบสวนตอประสานผูใชงาน

สิ่งที่ตองคํานึงถึงเมื่อทําการออกแบบสวนตอประสานผูใชงาน

ในสวนของการออกแบบสวนตอประสานผูใชงานนั้น ถือวาเปนศาสตรและศิลปในคราวเดียวกันท่ี

นักวิศวกรซอฟตแวรจะตองออกแบบซอฟตแวรใหท้ังสวยงามนาใชงาน และสามารถใชงานไดอยางมี

ประสิทธิภาพ ดังนั้นจึงมีสิ่งท่ีตองคํานึงถึงดังตอไปนี้

1. การกําหนดคาเริ่มตนใหกับระบบ เชน การกําหนดวันท่ี เวลาในการปรับปรุงขอมูลโดยผูใช

ไมจําเปนจะตองคียขอมูล เพ่ือลดความผิดพลาดอีกทางหนึ่งดวย

2. รูปแบบในการนําเสนอในระบบ ตองมีความสัมพันธกัน เชน การใชงานระบบจากซายไป

ขวา จากบนลงลาง และในรูปแบบซอฟตแวรเว็บแอบพลิเคชันแลวยิ่งตองแบงสวนของหนาจอใหสวยงาม

สอดคลองกัน

3. การกําหนดสี สีตัวอักษร สีพ้ืนหลัง และองคประกอบอ่ืนๆ เปนสิ่งท่ีจะเปนจะตองพิจารณา

เรื่องของโทนสีใหเขากันได ไมใชสีท่ีตัดกันอยางฉูดฉาด ทําใหผูใชงานรําคาญสายตาไดเม่ือใชระบบเปน

เวลานาน

4. การวางวัตถุ คอมโพเนน เพ่ือการใชงานท่ีเปนสากล ควรท่ีจะศึกษาถึงวิธีการวางตําแหนง

ของสิ่งตางๆ เชน ปุมตกลง ยกเลิก หรือการใชเมนูบาร การใชคียลัดตางๆ

5. การซอนและแสดงรายละเอียดอยางเหมาะสม รวมถึงการใชงาน ปอบอัพ เพ่ือการเตือน

เม่ือผูใชงานกําลังทําในสิ่งท่ีไมสอดคลองกัน หรือขอควรระวังตางๆ

6. การใหขอมูลขาวสารท่ีจําเปนกับผูใชงานเม่ือจําเปน สิ่งท่ีสําคัญคือใหผูใชงานไดทราบวา

ตําแหนงการใชงานปจจุบันนั้นอยูในสถานะใด การใหความชวยเหลือ (Help) ในระบบเพ่ือเปนแนวทางใน

การแกไขการทํางานเบื้องตน ตัวอยาง รูปแบบของการออกแบบสวนตอประสานผูใชงาน

7. ขอควรคํานึงถึงอ่ืนๆ ท่ีสําคัญในการออกแบบสวนตอประสานผูใชงาน การออกแบบสวนตอ

ประสานผูใชงานกาวหนาไปเรื่อยๆ หากตองการท่ีจะวัดประสิทธิภาพการทํางานของซอฟตแวรนั้น จะ

ปรากฏขอควรคํานึงถึงตางๆ คือ 1) เวลาตอบสนองของระบบ (System Response Time) 2) สิ่ง

1.วิเคราะห 2.สรางตนแบบ 3.ประเมิน

4.เอกสารตนแบบ 5.สรางตนแบบใชงาน

6.ตนแบบใชงาน 7.ส้ินสุดการสราง

121

อํานวยความช วยเหลือแกผู ใช (User Help Facilities) 3) การจัดการความผิดพลาด (Error

Information Handling) 4) การกําหนดชื่อคําสั่งและเมนู (Command and Menu Labeling)

ตัวอยางการออกแบบสวนตอประสานผูใชงาน

ระบบการแจงซอมอากาศยาน กองบิน 6 ฝูงบิน 604 วัตถุประสงคของโปรแกรมสําหรับติดตาม

ดูแลการแจงซอมอากาศยานของหนวยงานรวมถึงการติดตามการอนุมัติการซอมอากาศยาน แสดงตัวอยาง

ดังนี้

1. สวนของหนาหลักการแจงซอมอากาศยาน เปนสวนของหนาการทํางานหลักของโปรแกรม

การแจงซอมอากาศยาน ผูแจงซอมสามารถกรอกรายละเอียดขอมูลการแจงซอม เชน วันท่ีแจงซอม

คํานําหนาชื่อ ชื่อ นามสกุล ตําแหนง หนวยงาน เบอรโทร ประเภทและหมายเลขอากาศยาน อาการ

เบื้องตนโดยผูแจงซอมสามารถบันทึก และลางขอมูลได ดังภาพท่ี 10.2

ภาพท่ี 10.2 แสดงสวนของหนาหลักการแจงซอมอากาศยาน

122

2. สวนของหนาดูรายการซอมอากาศยาน สามารถแบงออกไดเปน 2 กรณี ดังนี้

กรณีท่ี 1 ผูใชงานเปนผูแจงซอม จะสามารถตรวจสอบขอมูลไดแคหนารายการซอม โดย

สามารถคนหาขอมูลไดจากชื่อผูแจงซอม

กรณีท่ี 2 ผูใชงานเปนผูดูแลระบบ จะสามารถทําการตรวจสอบไดทุกหนาการใชงานของ

โปรแกรม ดังภาพท่ี 10.3

ภาพท่ี 10.3 แสดงสวนของหนาดูรายการซอมอากาศยาน

3. สวนของหนาผูดูแลระบบเขาใชงานระบบ ทํางาน สวนของการเขาสูระบบ เม่ือกดปุมเขาสู

ระบบระบบจะทําการตรวจสอบกับฐานขอมูลในระบบ หากตรงกันกับฐานขอมูล ผูใชงานจึงจะสามารถเขา

ใชงานระบบได ดังภาพท่ี 10.4

ภาพท่ี 10.4 แสดงสวนของหนาผูดูแลระบบเขาใชงานระบบ

123

4. สวนของหนาดูประวัติการซอมอากาศยาน สวนของหนาดูประวัติการซอมอากาศยาน เม่ือ

ผูดูแลระบบไดทําการเขาสูระบบ ผูดูแลระบบจะสามารถเขามาดูประวัติการซอมอากาศยานยอนหลังได

หากผูดูแลระบบตองการทราบรายละเอียดของอากาศยานใหกรอกขอมูลประเภทการคนหา เลือกปุม

คนหา ดังภาพท่ี 10.5

ภาพท่ี 10.5 แสดงสวนของหนาดูประวัติการซอมอากาศยาน

5. สวนของหนาผูดูแลระบบท่ีจะตองดําเนินการอนุมัติเอกสาร ผูดูแลระบบจะตองเปน

ผูดําเนินการอนุมัติการซอมอากาศยาน กรณีไมอนุมัติการซอมอากาศยานผูดูแลระบบจะตองแจงไปยังผู

แจงซอมเพ่ือใหผูแจงซอมทราบถึงเหตุผลท่ีไมอนุมัติการซอม ดังภาพท่ี 10.6

ภาพท่ี 10.6 แสดงสวนของหนาผูดูแลระบบท่ีจะตองดําเนินการอนุมัติเอกสาร

124

บทสรุป

สําหรับข้ันตอนของการออกแบบสวนตอประสานผูใชงาน เปนข้ันตอนท่ีสําคัญอีกข้ันตอนหนึ่งท่ีได

นําเอาท้ังศิลปะและวิทยาศาสตร เพ่ือออกแบบซอฟตแวรใหนาใชงาน และมีประสิทธิภาพ มีบัญญัติในการ

ออกแบบสวนตอประสานท่ีนักวิศวกรรมซอฟตแวรควรจะตองพิจารณา การสรางแบบจําลองการวิเคราะห

และออกแบบสวนตอประสานผูใชงานนั้นจําเปนจะตองออกแบบใหเหมาะสมกับผูใชงาน จึงจะทําให

ผูใชงานเกิดความรูสึกพึงพอใจ โดยตองอาศัยกระบวนการแรออกแบบสวนตอประสาน ดังนี้ 1) วิเคราะห

2) สรางตนแบบ 3) ประเมิน 4) เอกสารตนแบบ 5) การสรางตนแบบใชงาน 6) ตนแบบใชงาน 7)

สิ้นสุดการสราง นอกจากนี้นักวิศวกรซอฟตแวรยังมีสิ่งท่ีตองคํานึงถึงเม่ือทําการออกแบบสวนตอประสาน

ผูใชงาน เชน การกําหนดคาเริ่มตน รูปแบบในการนําเสนอ การกําหนดสี การวางวัตถุ การซอนและ

แสดงรายละเอียด การใหขอมูลขาวสาร เปนตน สุดทายแสดงตัวอยางการออกแบบสวนตอประสาน

ผูใชงานของระบบการแจงซอมอากาศยาน กิองบิน 6 ฝูงบิน 604 สําหรับติดตามดูแลการซอมอากาศ

ยาน เพ่ือเปนประโยชนในการออกแบบสวนตอประสานผูใชงานตอไป


1. จงอธิบายความสําคัญของการออกแบบสวนตอประสานผูใชงานโดยใชปอนขอมูลได

หลายทางเลือก

2. จงอธิบายวิธีการสรางสวนตอประสานผูใชงาน

3. จงอธิบายเครื่องมือท่ีสามารถสรางสวนตอประสานผูใชงาน

4. จงยกตัวอยางท่ีแสดงใหเห็นปญหาของเวลาตอบสนองท่ีไมคงเสนคงวา

5. จงอธิบายสิ่งท่ีสําคัญ โดยสมมตวิานักศึกษาไดรับมอบหมายใหพัฒนาระบบธนาคารผานเว็บ

6. จงพัฒนารูปแบบจําลองผูใชงาน แบบจําลองการออกแบบ แบบจําลองสภาพจิตใจผูใชงาน

และแบบจําลองอิมพลเิมนตเทชัน

7. จงพัฒนาแบบสอบถามท่ีมีคําถาม 20 ขอ ท่ีอาจใชประเมินสสวนตอประสานผูใชงานท่ัวไป

ลองใชงานกับผูตอบแบบสอบถาม 10 คน และสรุปผลทํารายงาน

8. จงคนควา การออกแบบสวนตอประสานผูใชงานท่ีเปนท่ียอมรับ พรอมท้ังอธิบายพอสังเขป

9. จงอธิบายความสําคัญของการใชสีของตัวอักษร และพ้ืนหลังท่ีมีตอการออกแบบสวนตอ

ประสานผูใชงาน

10. จงอธิบายสิ่งท่ีสําคัญในการออกแบบสวนตอประสานผูใชงานสําหรับการใชงานขอมูลท่ีนําเขา

ดวยอุปกรณเฉพาะดาน เชน ระบบขายสินคาหนารานท่ีใชระบบบารโคด

125

อางอิง












(มหาชน).








what-cmmi.








Company.






126














Shneiderman Ben, Plaisant Catherine. “Design the user interface : Strategic for

effective human-computer interaction”. Pearson Education, 2005

Nielsen Jacob. “Designing Web Usability”. Indianapolis: Newriders Publishing, 2000.

127



1. ภาพรวมของการทดสอบระบบ

2. แนวทางการทดสอบซอฟตแวรเชิงยุทธวิธ ี

3. วิธีการคํานวณคุณภาพของซอฟตแวร

4. การคนหาสาเหตุจุดบกพรอง

5. ปจจัยท่ีไมสามารถคนหาจุดบกพรองของซอฟตแวร


1. นักศึกษาสามารถอธิบาย ภาพรวมของการทดสอบระบบ แนวทางการทดสอบซอฟตแวรเชิง

ยุทธวิธี วิธีการคํานวณคุณภาพของซอฟตแวร การคนหาสาเหตุจุดบกพรอง ปจจัยท่ีไมสามารถคนหา

จุดบกพรองของซอฟตแวรได

2. นักศึกษาสามารถแสดงวิธีการคํานวณคุณภาพของซอฟตแวรได



1.1 วิธีการสอนแบบบรรยาย เริ่มจากอธิบาย ภาพรวมของการทดสอบระบบ แนว

ทางการทดสอบซอฟตแวรเชิงยุทธวิธี วธิีการคํานวณคุณภาพของซอฟตแวร การคนหาสาเหตุ

จุดบกพรอง และปจจัยท่ีไมสามารถคนหาจุดบกพรองของซอฟตแวร




2.1 แสดงตัวอยางตัวอยางวิธีการคํานวณคุณภาพของซอฟตแวร

2.2 แบงกลุมอภิปรายเรื่องทําไมการคนหาสาเหตุของจุดบกพรองถึงเปนเรื่องยาก


128









129

บทท่ี 11

การทดสอบซอฟตแวร

ในบทนี้จะกลาวถึงภาพรวมของการทดสอบระบบ ซ่ึงเปนข้ันตอนท่ีสําคัญ การทดสอบระบบนั้น

เพ่ือคนหาความผิดปกติท่ีอาจจะเกิดข้ึนกับการทํางานของซอฟตแวร สิ่งท่ีตองคํานึงถึงคือ กําหนดสิ่งท่ี

ตองการทดลอง กระบวนการ และการยอมรับ ดังนั้นจึงมีแนวทางการทดสอบซอฟตแวรเชิงยุทธวิธี

เรียกวา การตรวจทานและการตรวจรับ นอกจากนี้นักทดสอบระบบจําเปนตองใชวิธีคํานวณคุณภาพของ

ซอฟตแวรและเพ่ือสรางความเชื่อสําหรับการใชงาน โดยแบงเปน 2 สวน คือ การวัดคุณภาพของสวนตอ

ประสาน และการวัดคุณภาพของสวนการพัฒนาโคด การคนหาสาเหตุจุดบกพรองเปนข้ันตอนท่ีมุงหวัง

ทําการแกไขขอผืดพลาดของซอฟตแวรและแกไขใหถูกตอง สุดทายคือปจจัยท่ีนักทดสอบไมสามารถ

คนหาจุดบกพรองของซอฟตแวรได เชน ความซับซอนของซอฟตแวร อาจจะทําใหการคนหาจุดบกพรอง

ยากเกินไปดวย

ภาพรวมของการทดสอบระบบ

การทดสอบเปนปราการดานสุดทายท่ีประเมินคุณภาพและคนพบขอผิดพลาด แตการทดสอบ

ไมใชเครื่องรับประกันความปลอดภัย การตรวจทานดานเทคนิคอยางเปนทางการ การจัดการท่ีเขมแข็ง

และการวัดผลท้ังหลายท่ีนําไปสูคุณภาพ สิ่งเหลานี้อาจพิสูจนยืนยันไดระหวางข้ันตอนการทดสอบ

1. กําหนดสิ่งท่ีตองการทดสอบ (Component) เปนการทําตามกระบวนการของซอฟตแวร

หรือเปนการตั้งสมุติฐานของสิ่งท่ีตองการจะทําการทดทสอบ

2. กระบวนการทดสอบ (Testing) เปนการทดสอบการใชงานของซอฟตแวร และบันทึกผลจาก

การใชงานเหลานั้น

3. การยอมรับ (Accepted) เปนการยอมรับถึงผลการทดสอบ หากมีการปรับปรุงแกไขให

เริ่มทําการทดสอบใหมอีกครั้ง ดังภาพท่ี 11.1

ภาพท่ี 11.1 แสดงข้ันตอนของการทดสอบระบบ

130

แนวทางการทดสอบซอฟตแวรเชิงยุทธวิธ ี

สําหรับนักทดสอบระบบนั้นจําเปนจะตองทําการทดสอบระบบเพ่ือใหม่ันใจวาซอฟตแวรท่ี

พัฒนาข้ึนนั้นสามารถใชงานไดอยางถูกตอง โดยมีวิธีการทดสอบดังนี้

1. การทดสอบซอฟตแวร เปนสวนประกอบหนึ่งของหัวขอท่ีเรียกวา การตรวจทานและการ

ตรวจรับ หรือ วี แอนด วี (Verification and Validation)

การตรวจทาน (Verification) หมายความถึง ชุดของกิจกรรมท่ีประกันวา ซอฟตแวรไดทําตาม

หนาท่ีเฉพาะท่ีกําหนดข้ึน

การตรวจรับ (Validation) หมายความถึง ชุดของกิจกรรมท่ีตางออกไป ท่ีประกันวา

ซอฟตแวรท่ีสรางข้ึนเปนไปตามความตองการของลูกคา

2. การจัดระเบียบการทดสอบซอฟตแวร มีความเขาใจผิดพลาดท่ีควรกลาวถึงอยู เชน นักพัฒนา

ซอฟตแวรไมควรทําการทดสอบ ซอฟตแวรควรจะสงมอบใหกับคนแปลกหนาท่ีจะทดสอบอยางไมปรานี

นักทดสอบมาเก่ียวของกับโครงการเม่ือข้ันตอนการทดสอบกําลังจะเริ่มข้ึน คํากลาวท้ังหมด เปนคํากลาว

ท่ีไม ถูกตอง นักพัฒนาการซอฟตแวรตองรับผิดชอบในการทดสอบหนวยยอยแตละหนวยท่ีเปน

องคประกอบของโปรแกรมเพ่ือยืนยันวาแตละองคประกอบทํางานตามหนาท่ีหรือแสดงพฤติกรรมตาม

แบบท่ีออกมา ในหลายๆ ครั้ง นักพัฒนาซอฟตแวรทําการทดสอบระดับบูรณาการดวย ซ่ึงเปนข้ันตอนท่ี

นําไปสูการประกอบสถาปตยกรรมซอฟตแวรใหสมบูรณ เม่ือสถาปตยกรรมซอฟตแวรสมบูรณแลวกลุมนัก

ทดสอบอิสระจึงมาเก่ียวของดวย

3. กลยุทธการทดสอบซอฟตแวรสําหรับสถาปตยกรรมเชิงวัตถุ กลยุทธโดยรวมสําหรับ

ซอฟตแวรเชิงวัตถุ มีปรัชญาเชนเดียวกันกับสถาปตยกรรมแบบดั้งเดิม แตมีแนวทางแตกตางกัน กลาวคือ

เราจะเริ่มดวยการทดสอบชิ้นงานขนาดเล็กกอน จากนั้นก็เคลื่อนไปทดสอบชิ้นงานขนาดใหญข้ึน แต

ชิ้นงานขนาดเล็กไดเปลี่ยนจากโมดูลแตละโมดูลไปเปนคลาสท่ีรวมเอาคุณสมบัติและตัวกระทําการ และมี

นัยถึงการติดตอสื่อสารและการรวมมือกันทํางานดวย เม่ือหลายๆ คลาสรวมกันเปนสถาปตยกรรมเชิงวัถตุ

ชุดของการทดสอบเชิงถดถอยจะทํางาน เพ่ือเปดเผยถึงขอผิดพลาดอันเนื่องมาจากการสื่อสารและการ

รวมกันทํางานระหวางคลาสท่ีเปนองคประกอบ รวมถึงผลขางเคียงท่ีเกิดจากคลาสใหมๆ

4. กลยุทธการทดสอบสําหรับซอฟตแวรแบบด้ังเดิม ซ่ึงประกอบดวย 4 การทดสอบ คือ การ

ทดสอบระดับหนวย การทดสอบระดับบูรณาการ การทดสอบระดับหนวยในบริบทเชิงวัตถุ และการ

ทดสอบระดับบูรณาการในบริบทเชิงวัตถุ

131

การทดสอบระดับหนวย เจาะจงทดสอบหนวยท่ีเล็กท่ีสุดของงานออกแบบซอฟตแวร คือ

องคประกอบซอฟตแวร (Component) หรือโมดูลซอฟตแวร (Module) โดยใชคําอธิบายประกอบการ

ออกแบบระดับองคประกอบ เปนแนวทางทดสอบเสนทางควบคุมหลัก เพ่ือคนหาขอผิดพลาดภายใน

ขอบเขตของโมดูล ความซับซอนสัมพัทธของการทดสอบและขอผิดพลาดท่ีการทดสอบคนหาได จะถูก

จํากัดดวยขอบเขตของการทดสอบระดับหนวย การทดสอบระดับหนวยเจาะจงทดสอบตรรกะ

กระบวนการทํางานภายใน และโครงสรางขอมูลภายในขอบเขตขององคประกอบ การทดสอบชนิดนี้

สามารถทําพรอมๆ กันไปหลายๆ องคประกอบ

การทดสอบระดับบูรณาการ เปนเทคนิคอันมีระเบียบแบบแผน สําหรับการสรางสถาปตยกรรม

ซอฟตแวร ขณะท่ีทําการทดสอบเพ่ือเปดเผยความผิดพลาดท่ีแฝงมากับการอินเตอรเฟส วัตถุประสงคคือ

นําองคประกอบท่ีผานการทดสอบระดับหนวยแลวมากอเปนโครงสรางโปรแกรมตามท่ีออกแบบไว

การทดสอบระดับหนวยในบริบทเชิงวัตถุ เราไมสามารถทดสอบตัวดําเนินการหนึ่งอยางอิสระ

ดังท่ีเคยทําซอฟตแวรท่ัวๆ ไป แตตองทดสอบเปนสวนหนึ่งของคลาส ลองพิจารณาลําดับชั้นของคลาสท่ีมี

ตัวดําเนินการ X ท่ีนิยามไวสําหรับคลาสแมและถูกถายทอดสูคลาสลูกจํานวนหนึ่ง คลาสลูกแตละคลาส

ตางใชตัวดําเนินการ X แตใชกับแอตทริบิวสสสวนตัวและตัวดําเนินการอ่ืนๆ ท่ีกําหนดสําหรับคลาสตนเอง

เทานั้น เพราะวาตัวดําเนินการ X ภายใตสภาพแวดลอมของแตละคลาสลูก ซ่ึงหมายความวาการทดสอบ

ตัวดําเนินการ X อยางอิสระแบบเดิมจะใชไมไดผลในบริบทเชิงวัตถุ

การทดสอบระดับบูรณาการในบริบทเชิงวัตถุ ซอฟตแวรเชิงวัตถุไมมีโครงสรางการควบคุม

ตามลําดับข้ันท่ีชัดเจน ดังนั้นการทดสอบระดับบูรณาการจากบนลงลาง หรือลางข้ึนบนจึงไรความหมาย

นอกจากการรวมตัวดําเนินการทีละตัวเขากับคลาสมักจะเปนไปไมได เพราะปฏิกิริยาโดยตรงและโดยออม

ขององคประกอบท่ีประกอบกันข้ึนเปนคลาส

วิธีการคํานวณคุณภาพของซอฟตแวร

การพัฒนาซอฟตแวรใหมีคุณภาพท่ีดีนั้นถือเปนเปาหมายของนักวิศวกรซอฟตแวร ในทางเทคนิค

แลวนักวิศวกรซอฟตแวรจะทําการสรางโมเดลท่ีเหมาะสมกับงาน และทําตามกระบวนการอยางมีข้ันตอน

มาระยะหนึ่งแลว เม่ือโปรแกรมเริ่มพัฒนาข้ึนมาจึงจําเปนท่ีจะตองมีการตรวจสอบคุณภาพของซอฟตแวร

ซ่ึงอาจจะเปนการทดสอบจากตนแบบ หรือแบบจําลองการใชงานของโปรแกรม ขอดีของการวัดคุณภาพ

ของซอฟตแวรนี้ จะทําใหสรางความเชื่อม่ันสําหรับการใชงาน ชวยวิเคราะหถึงปญหาท่ีอาจจะเกิดข้ึนใน

อนาคตได นักวิศวกรซอฟตแวรสามารถวัดคุณภาพดวยวิธีการดังนี้

132

1. การวัดคุณภาพของสวนตอประสาน (Interface Design Metrics) สวนตอประสานมี

ความสําคัญมากตอการสรางซอฟตแวรข้ึนมาเพ่ือใหผูใช สามารถใชงานไดอยางมีประสิทธิภาพท่ีสุด สิ่งท่ี

แสดงผลบนหนาจอ เรียกวา Layout appropriateness (LA) เปนสวนท่ีทําหนาท่ีสื่อสารกับผูใชงาน

ประกอบดวย Layout Enitity จํานวนมากเชน ตัวหนังสือ กลองขอความ ปุมควบคุมการทํางาน เปนตน

ดังนั้นการหาตนทุน (Cost) หรือความเหมาะสมของการออกแบบหนาจอนั้นจึงมีวิธีการคํานวณดังสมการ

ตอไปนี้

∑ ×= )]k(transition_of_tcos)k(transition_of_frequency[tcos

เม่ือ transition_of_frequency คือความถ่ีท้ังหมดของการทํางานท่ีเก่ียวของกับสวนของการแสดงผล

k คือจํานวนของการทํางานฟงกชันพิเศษ

การหารูปแบบการจัดวางสวนติดตอผูใชงานท่ีเหมาะสม Layout appropriateness (LA)

สามารถคํานวณไดจากสมการนี้

)]layout_proposed_of_t/(cos)layout_optimalLA_of_t[(cosLA −×=100

เม่ือ 100=LA คือ layout_ptimal

layout_ptimal คือสวนติดตอผูใชงานท่ีเหมาะสม

2. การวัด คุณภาพของสวนการพัฒนาโคด (Metrics for source code) คุณภาพของ

ซอฟตแวรนั้นจะสามารถทํางานไดอยางเต็มประสิทธิภาพหรือไมนั้น จําเปนอยางยิ่งท่ีตองพิจารณาถึงการ

เขียนโปรแกรม สามารถวัดไดจากความยาวจากบรรทัดของการเขียนโปรแกรม (Program length)

แนวโนมของผลลัพธท่ีไดจากอัลกอริทึม (potential volume for an algorithm) ในบางครั้งรูปแบบการ

เขียนโปรแกรมดวยวิธีอันซับซอนจึงจําเปนตองมีวิธีการคํานวณเพ่ือวัดประสิทธิภาพของสวนการพัฒนโคด

ดังสมการตอไปนี้

222121 nlognnlognN +=

เมือ N คือความยาวของโคดโปรแกรม

21 n,n คือจํานวนของการทํางาน (Operation) ท่ีแตกตางกันปรากฏในโปรแกรม

การคํานวณหาคาของโปรแกรมสามารถคํานวณจากสมการตอไปนี้

)nn(logNV 212 +=

เม่ือ V คือภาษาโปรแกรมและขอมูลตางท่ีถูกนําเขาในโปรแกรมในรูปของบิต (Bit)

133

การคนหาสาเหตุจุดบกพรอง

การคนหาสาเหตุของจุดบกพรอง (Debugging) เปนผลสืบเนื่องจากการทดสอบท่ีสัมฤทธิ์ผล

นั่นคือ เม่ือกรณีทดสอบคนพบขอผิดพลาด การคนหาสาเหตุของจุดบกพรองเปนการกระทําท่ีมุงหวัง จะ

ขจัดความผิดพลาดท่ีคนพบ แมวาการคนหาสาเหตุของจุดบกพรองนาจะเปนกระบวนการอันมีระเบียบ

แตก็ยังเปนศิลปะอยูมาก หลังจากประเมินผลการทดสอบ นักวิศวกรซอฟตแวรมักจะเผชิญกับตัวบงชี้

อาการของปญหาซอฟตแวร กลาวคือ อาการภายนอกท่ีแสดงออกของขอผิดพลาดกับสาเหตุภายในของ

ความผิดพลาด อาจจะไมมีความสัมพันธตอกันท่ีชัดเจน กระบวนการทางจิตใจท่ีเรายังไมเขาใจท่ีดีสามารถ

เชื่อมอาการกับสาเหตุเรียกวา การคนหาสาเหตุของจุดบกพรอง (Debugging) การคนหาสาเหตุมักมี

ผลสัมฤทธิ์ 2 ประการ คือ 1) สาเหตุของปญหาถูกคนพบและไดรับการแกไข 2) สาเหตุของปญหาไมถูก

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

เดา งานท่ีนําไปสูการแกไขขอผิดพลาดมีลักษณะวนซํ้า

ปจจัยที่ไมสามารถคนหาจุดบกพรองของซอฟตแวร

การคนหาจุดบกพรองของซอฟตแวรนั้น เปนหนาท่ีหลักของการทดสอบระบบ ในบางครั้งอาจจะ

ไมสามารถคนหาจุดบกพรองไดอาจจะเกิดจากสาเหตุดังตอๆ ไปนี้

1. อาการและสาเหตุอาจจะไมเคยปรากฏมากอน นั่นคืออาการอาจปรากฏข้ึนท่ีสวนหนึ่งของ

โปรแกรม การมีองคประกอบและการทํางานของซอฟตแวรท่ีซับซอน ทําใหการคนหาจุดบกพรองของ

ซอฟตแวรนั้นยากข้ึนตามไปดวย

2. อาการอาจหายไปชั่วคราวเม่ือขอผิดพลาดอ่ืนถูกแกไข

3. อาการอาจเกิดข้ึนจากสาเหตุท่ีไมใชขอผิดพลาด

4. อาการเกิดจากสาเหตุท่ีไมใชขอผิดพลาด

5. อาการอาจเปนผลของปญาเก่ียวกับเวลา มากกวาปญหาดานกระบวนการ

6. อาจเปนการยากท่ีจะสรางเง่ือนไขขอมูลเขาซํ้าเติมไดอีก

7. อาการอาจอยูเพียงชั่วครูชั่วยาม ซ่ึงเกิดข้ึนเปนธรรมดาในระบบฝงตัวท่ีเชื่อมฮารดแวรเขา

ดวยกันอยางแยกไมออก

8. อาการอาจสืบเนื่องจากสาเหตุท่ีกระจายครอบคลุมงานยอยจํานวนหนึ่ง ท่ีทํางานบนหนวย

ประมวลผลท่ีแตกตางกัน

134

บทสรุป

การทดสอบซอฟตแวร เปนงานท่ีตองใชทรัพยากรท้ังบุคลากรและความเอาใจใสเชิงเทคนิคสวน

ใหญในกระบวนการซอฟตแวร แตกระนั้นเราเพียงเริ่มตนท่ีจะเขาใจความล้ําลึกของการวางแผนการ

ทํางานและการควบคุมการทดสอบเทานั้น วัตถุประสงคของการทดสอบซอฟตแวรแทจริงนั้นคือการคนหา

ขอผิดพลาดท่ีเกิดข้ึนหรือกําลังจะเกิดข้ึนท้ังจากระบบและผูพัฒนา เพ่ือบรรลุวัตถุประสงคนี้ นักทดสอบ

ระบบจําเปนจะตองมองภาพรวมของการทดสอบระบบ หาแนวทางการทดสอบซอฟตแวรเชิงยุทวิธี

ดําเนินการหาวิธีการคํานวนคุณภาพของซอฟตแวร เพ่ือคนหาจุดบกพรองของซอฟตแวรรวมถึงคนหา

ปจจัยท่ีไมสามารถคนหาจุดบกพรองของซอฟตแวรได


1. จงอธิบายหนาท่ีของนักทดสอบระบบ

2. จงอธิบายความแตกตางระหวางการตรวจทาน (Verification) และการตรวจรับ (Validation)

วาท้ังคูใชงานการออกแบบกรณีทดสอบและกรณีกลยุทธการทดสอบหรือไม อยางไร

3. จงอธิบายเพราะเหตุใดโมดูลท่ีเชื่อมโยงกันมาก จึงทําใหการทดสอบระดับหนวยไดยาก

4. จงอธิบายหนาท่ีของผูทําการตรวจสอบการตรวจรับ (Validation Test)

5. จงอธิบายตารางการทํางานของโครงการวามีผลกระทบตอการทดสอบระดับบูรณาการอยางไร

6. จงอธิบายกลยุทธการทดสอบสําหรับซอฟตแวรแบบดั้งเดิม

7. จงอธิบายกลยุทธการทดสอบซอฟตแวรสําหรับสถาปตยกรรมเชิงวัตถุ

8. จงอธิบายการทดสอบระดับหนวยยอย (Unit)

9. จงอธิบายความสําคัญของวิธีการคํานวณคุณภาพของซอฟตแวร การวัดคุณภาพของสวน

ติดตอผูใชงาน

10. จงอธิบายความสําคัญของวิธีการคํานวณคุณภาพของซอฟตแวร การวัดคุณภาพของสวนการ

พัฒนาโคด

135

บรรณานุกรม

กิตติ ภักดีวัฒนะกุล และ พนิดา พานิชกุล. (2550). วิศวกรรมซอฟตแวร (พิมพครั้งท่ี 1). กรุงเทพฯ:

บ.ซีเอ็ดยูเคชัน จํากัด (มหาชน)







น้ําฝน อัศวเมฆิน. (2558). หลักพ้ืนฐานของวิศกวรรมซอฟตแวร. (พิมพครั้งท่ี 2). กรุงเทพฯ:

บ.ซีเอ็ดยูเคชัน จํากัด (มหาชน)

วิทยา สุคตบวร. (2008). วิศวกรรมซอฟตแวร เบื้องตน (พิมพครั้งท่ี 1). กรุงเทพฯ: บ.ซีเอ็ดยูเคชัน จํากัด

(มหาชน)

สมชาย กิตติชัยกุลกิจ. (2548). เรื่องซอฟตแวรมีแคนี้. กรุงเทพฯ:สมาคมสงเสริมเทคโนโลยีไทย (ไทย-



Software Park. (2006). มาตรฐานกระบวนการในการพัฒนางาน (CMMI). คนวันท่ี 11 มกราคม

2559, จากhttp://www.swpark.or.th/cmmiproject/index.php/general/73-what-cmmi.


Company.


Engineering",Publication in IJCSI International Journal of Computer Science,

ISSN(Online):1694-0814,Issues,Vol.7,Issue5,September2010.



Schwaber, K. (2004). Agile Project Management with Scrum. Seattle: Microsoft Press.

Borland. “CaliberRM Enterprise Software Requirements Management

System”.(2012), คนวันท่ี 26 มกราคม 2559, จาก

http://www.Borland.com/us/products/Caliber/index.html





136




Shneiderman Ben, Plaisant Catherine. “Design the user interface : Strategic for

effective human-computer interaction”. Pearson Education, 2005

Nielsen Jacob. “Designing Web Usability”. Indianapolis: Newriders Publishing, 2000.

เอกสารประกอบการสอนรายวิชา 5003107 … · 2 2....

Documents