software engineering

วิชาการ # cstu20
เอกสารอานประกอบสไลดชุดที่ 2 ( 01Software_Process.ppt)
http://course.cs.tu.ac.th

Introduction to software engineering

Software process เปนกลุมของวิธีการทํางานหลาย ๆ แบบตาง ๆ กัน ซึ่งกลุมการทํางานตาง ๆ เหลานั้น

อาจจะแบงออกไดเปน 4 กลุมใหญ ๆ ดังนี้
1. Specifying กําหนดความตองการของลูกคาที่อยากใหระบบเปน
2. Designing การออกแบบระบบโดยใช model หรืออื่น ๆ เพื่อใหระบบตรงกับความตองการของลูกคา
3. Implementing การเปลีย่ น design ใหเปน code มาเปน programming และ debugging เมื่อเสร็จ
ขั้นตอนนี้จะได software product 1 อัน
4. Testing การทดสอบ software product ที่ไดจากขั้นตอนที่แลว วาตรงตามความตองการของลูกคาเพียงใด
ตองไดรับการแกไขหรือไม

Software process ประกอบดวย 4 ขั้นตอนหลัก ดังนี้

1. Specification การกําหนดความตองการของลูกคา
2. Design ออกแบบระบบ
3. Validation ทดสอบความถูกตองของระบบ
4. Evolution พัฒนาหลังจากที่ระบบเสร็จสิน ้ แลว หากมีความตองการจากลูกคา
ขอสังเกต implementing จะเชื่อมอยูระหวางขั้นตอน design และขั้นตอน validation ไมสามารถแยกออก
จากกันไดชัดเจน เพราะในบางครั้งการ design ตองทําไปพรอม ๆ กับการ programming และในทํานอง
เดียวกันบางครั้งก็มีการทดสอบระบบไปพรอม ๆ กับ programming ดวย
Software process model คือ โมเดลที่ใชแสดงการทํางานของระบบในมุมมองตาง ๆ ขึ้นอยูกับวาเรา
ตองการ และสนใจระบบในมุมมองใด ( อานรายละเอียดไดในชีตชุดที่แลว )

1. waterfall model จะแยกขั้นตอนตาง ๆ ออกจากกันอยางชัดเจน เชน requirement specification ,

software design , implementation , testing และอื่น ๆ ( การแยกขั้นตอนไมจําเปนจะตองเหมือนกันทุก
ครั้งขึ้นอยูกับวา software engineer ตองการใชขั้นตอนใดบางในการพัฒนา software ) ลักษณะเดนของ
waterfall model คือ เมื่อสิ้นสุดการทํางานใน ขั้นตอนใด ขั้นตอนหนึ่งแลวจะไมมีการกลับไปทําขั้นตอนนั้นอีก
2. Evolutionary development model นี้มีการซอนกันของขั้นตอน specification ,
development และ validation ลักษณะเดนของการพัฒนาแบบนี้ คือ จะมีการสราง system ในขั้นตอนแรก
อยางรวดเร็ว เพื่อใหเห็นภาพคราว ๆ หลังจากนั้น ลูกคาจะเปนคนบอกวาตองการใหพัฒนาไปในทิศทางใด ซึ่งใน
บางครั้งการพัฒนาโดยใช model นี้จะสงผลให system มี structure ที่ดี เนื่องจากไมไดมกี ารออกแบบไวกอน
แตใชวิธีคอย ๆ เปลี่ยนไปเรื่อย ๆ ( ซึ่งเปน model ที่เราใชในการพัฒนา assign มาตลอด )
3. formal system development การพัฒนาแบบนี้จะเนนขั้นตอน specification ในขั้นตอนนี้จะมี
การเปลี่ยนแปลงความตองการของลูกคาใหเปนสมการทางคณิตศาสตรที่แนนอน และมีความผิดพลาดนอย หลังจาก
นั้นจึงเปลี่ยนเปน code ในขั้นตอนของการ implementing จุดเดนของการพัฒนาแบบนี้คือ มีความแมนยําสูง
มีความผิดพลาดนอยมาก มักจะใชในการพัฒนาระบบที่ไมอาจจะเกิดความผิดพลาดไดเลย เชน การพัฒนา software
ควบคุมการทํางานของหัวใจเทียม

4. Reuse – base development การพัฒนาแบบนี้จะเปนการใช component ( สวนประกอบยอย ๆ

ของโปรแกรม ) มาประกอบกัน เปน system ใหญ ในการออกแบบ component แตละอันจะมีการ design
เพื่อใหใชประโยชนตอไปไดในอนาคต การพัฒนาในรูปแบบนี้กําลังจะกลายเปนหัวใจสําคัญใน software
engineering ยุคใหม อยางไรก็ตาม ในปจจุบันนี้ความรูในเรื่องนี้ยังมีไมมากพอที่จะกําหนดเปนทฤษฎีไดอยาง
ตายตัว
waterfall model

Requirement
definition

design

Implementing and
unit testing

1
Integration and
testing

Operation and
maintenance

เมื่อวิเคราะหจาก diagram จะสังเกตวา water model จะไมมีการยอนกลับไปยังขั้นตอนที่เสร็จเรียบรอยแลว

( ตามลูกศรสีฟา ) แตเมื่อระบบเสร็จสิ้น อาจจะมีความตองการเปลีย่ นแปลง( evolution ) ในตอนนี้เราสามารถ
กลับไปเริ่มพัฒนาที่ขั้นตอนใดขั้นตอนหนึ่งได เชน ตองมีการ design ใหม เราจะกลับไป ตามลูกศรหมายเลข 1
เพื่อไปยังขั้นตอน design หลังจากนั้น process จะดําเนินตาม water model จนจบการทํางานที่
operation and maintenance อีกครั้ง
อยางไรก็ตามในการใชงานจริง ๆ แตละขั้นตอนมักจะมีสวนที่เหลื่อมล้ํากันอยู ตัวอยางเชน เมื่อถึงขั้นตอนของการ
implementing หรือการ programming อาจจะพบวาการ design มีปญหา จึงตองกลับไปแกตัว design
กอน
ปญหาของ waterfall model คือ มีการแบงขั้นตอนออกเปนสวน ๆ มากเกินไป ทําใหยอนกลับไปไดยาก หากมี
ความตองการเปลี่ยนแปลงจากลูกคา ดังนั้น model นี้จึงเหมาะกับการพัฒนา software product ที่มีความ
เขาใจใน requirement เปนอยางดี เพื่อจะไดไมตองกลับไปแกไขในขั้นตอนแรก ๆ
2. Evolutionary development มีการซอนกันของขัน้ ตอน specification , development (
design + implementation ) และ validation

Specification Initial version

Intermediate
Outline description Development version

Validation Final version

จะเห็นวาจะเริ่มตนดวยการสราง initial version ขึ้นมากอน แลวใหลูกคาดู ( สี่เหลี่ยมใหญ ที่ 3 ขั้นตอนหลักซอน

กันอยูเปนขั้นตอนที่ลูกคาจะมีสวนรวมในการพัฒนา ) หลังจากนั้นจะทําการไปในทิศทางทีล่ ูกคาตองการ และมีการ
ทดสอบอยูเรื่อย ๆ ผลลัพธที่ไดจากการทดสอบทีไ่ ดจากการพัฒนาเรียกวา intermediate version ( จะเห็นวาเกิด
intermediate version ขึ้นหลายอัน เนื่องจากลูกคาอาจจะมีการปรับปรุงหรือเปลี่ยนแปลงความตองการใน
ระหวางการพัฒนา ) เมื่อลูกคาพอใจกับระบบที่ไดรับการพัฒนาแลว การทดสอบสุดทายจะไดผลลัพธเปน
final version และสงลูกคาตอไป
Evolutionary development แบงออกเปน 2 แบบ
1. Exploratory development เปน evolutionary แบบตรง ๆ คือจะพัฒนาไปพรอม ๆ กับลูกคาเพื่อ
คนหาความตองการของลูกคา และพัฒนา final system ออกมา การเริ่มตนของการพัฒนาแบบนี้จะเริ่มจากสวนที่
software engineer เขาใจตรงกับลูกคาที่สด
ุ กอน แลวคอย ๆ เพิ่มองคประกอบตาง ๆที่ลูกคาตองการเขาไป

2. Throw – away prototyping ขอแตกตางของแบบ phototype กับแบบ exploratory คือแบบ

phototype จะเริ่มตนจากความไมคอยเขาใจใน requirement ของลูกคา จึงสรางระบบแบบหยาบ ๆ เรียกวา
phototype ขึ้นมากอนแลวสงใหลูกคาดูและ comment กลับมา แลวจึงทําการปรับปรุงระบบใหเปนไปตาม
ความตองการของลูกคาจนกวาจะได final version ตามตองการ เหมาะกับการพัฒนาระบบที่มี requirement
ที่เขาใจยาก

ตัวอยางของการพัฒนาดวยวิธี Exploratory development คือการพัฒนาระบบ AI ซึ่งเราพยายามจะทําให

computer สามารถคิดไดเหมือนคน แตในปจจุบันเรายังไมสามารถที่จะระบุ specification ที่แนนอนในเรื่องนี้
ได จําเปนจะตองมีการพัฒนาและทดสอบ จนกวาจะตรงกับความตองการ

ปญหาของ evolutionary
1. ไมมีความชัดเจนวาในปจจุบันพัฒนาอยูในขั้นตอนไหน คือ specification development และ
validation ซอนทับกันอยู ทําใหระบุไมไดวาขั้นตอนที่ทํางานอยูปจจุบันคือขั้นตอนใด
2.ระบบจะมี structure ที่ไมดี เพราะขาดการออกแบบไวกอน แตใชวิธีคอย ๆ เพิ่มไปเรื่อย ๆ ทําใหในบางครั้ง
program อาจจะมีการใชงาน resource มากเกินความจําเปน
3. ทีมงานในการพัฒนาจําเปนจะตองมีความสามารถมากเปนพิเศษ มีความเชี่ยวชาญในแตละดานที่รับผิดชอบสูง
เพราะเมื่อลูกคาแสดงความตองการจะตองสามารถพัฒนาเปนไปตามทีล่ ูกคาตองการไดในทันที หากขาดสวนนี้ไป
เวลาที่ใชในการพัฒนาระบบ จะมากเกินความจําเปน

จากปญหาทีก่ ลาวมา ทําใหการพัฒนาดวยวิธีนี้ไมเหมาะกับการพัฒนาที่มีระบบขนาดใหญ โดยมากจะใชในการพัฒนา

ระบบที่มีอายุการใชงานสั้น ๆ หรือระบบที่เปนสวนประกอบของระบบสวนใหญ ๆ