Cs284 Waterfall Evolution

software engineering

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

เปนกลุมของวิธีการทํางานหลาย ๆ แบบตาง ๆ กัน ซึ่งกลุมการทํางานตาง ๆ เหลานั้น อาจจะแบงออกไดเปน 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

คือ โมเดลที่ใชแสดงการทํางานของระบบในมุมมองตาง ๆ ขึ้นอยูกับวาเรา ตองการ และสนใจระบบในมุมมองใด ( อานรายละเอียดไดในชีตชุดที่แลว )

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 design + implementation )

มีการซอนกันของขัน้ ตอน specification , development (

และ validation

Specification

Outline description

Development

Validation

Initial version

Intermediate version

Final version

จะเห็นวาจะเริ่มตนดวยการสราง initial version ขึ้นมากอน แลวใหลูกคาดู ( สี่เหลี่ยมใหญ ที่ 3 ขั้นตอนหลักซอน กันอยูเปนขั้นตอนที่ลูกคาจะมีสวนรวมในการพัฒนา ) หลังจากนั้นจะทําการไปในทิศทางทีล่ ูกคาตองการ และมีการ ทดสอบอยูเรื่อย ๆ ผลลัพธที่ไดจากการทดสอบทีไ่ ดจากการพัฒนาเรียกวา intermediate version ( จะเห็นวาเกิด intermediate version ขึ้นหลายอัน เนื่องจากลูกคาอาจจะมีการปรับปรุงหรือเปลี่ยนแปลงความตองการใน ระหวางการพัฒนา ) เมื่อลูกคาพอใจกับระบบที่ไดรับการพัฒนาแลว การทดสอบสุดทายจะไดผลลัพธเปน final version และสงลูกคาตอไป

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

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. ทีมงานในการพัฒนาจําเปนจะตองมีความสามารถมากเปนพิเศษ มีความเชี่ยวชาญในแตละดานที่รับผิดชอบสูง เพราะเมื่อลูกคาแสดงความตองการจะตองสามารถพัฒนาเปนไปตามทีล่ ูกคาตองการไดในทันที หากขาดสวนนี้ไป เวลาที่ใชในการพัฒนาระบบ จะมากเกินความจําเปน จากปญหาทีก่ ลาวมา ทําใหการพัฒนาดวยวิธีนี้ไมเหมาะกับการพัฒนาที่มีระบบขนาดใหญ โดยมากจะใชในการพัฒนา ระบบที่มีอายุการใชงานสั้น ๆ หรือระบบที่เปนสวนประกอบของระบบสวนใหญ ๆ