บทที่ 3 Software Process กระบวนการต่างๆในการพัฒนา SW

บทนี้จะพูดถึงขั้นตอนใหญ่ๆ กระบวนการใหญ่ๆ และก็วิธีการหรือ Model ที่ใช้ในการพัฒนา SW

The Software Process < Slide 3 > จะมีอยู่ 4 ขั้นตอนใหญ่ๆดังนี้

1. Specification คือ ขั้นตอนการกำหนดคุณสมบัติและความต้องการของระบบ
2. Design คือ ขั้นตอนการออกแบบระบบ หรือ ออกแบบตัว SW
3. Validation คือ รวมตั้งแต่การพัฒนาขึ้นมาและทดสอบว่ามันใช้งานได้จริงตามต้องการหรือเปส่า
4. Evolution คือ พัฒนาการของ SW ที่มีการปรับเปลี่ยนไปตามความต้องการหรือความเหมาะสมให้มีประสิทธิภาพมากขึ้น

Generic Software Process Models < ในตำราเล่มนี้จะอ้างถึง 4 วิธีใหญ่ๆ >

1. Waterfall Model
- นิยมใช้มากที่สุด
- เป็นการพัฒนาระบบหรือ SW ที่เป็นลำดับขั้น โดยมีขั้นตอนกำหนดไว้แต่แรกแล้วว่าจะทำอะไรบ้างเป็นขั้นๆไปโดยชัดเจน

2. Evolutionary Development
- การพัฒนา SW ในลักษณะที่ทำให้เกิดการพัฒนาปรับปรุงไปเรื่อยๆ
- เป็นการรวบรวมความต้องการของระบบขึ้นมาระดับหนึ่ง แล้วพัฒนาตามนั้น แล้วก็มาดูว่ามีคุณสมบัติอะไรอีกบ้างที่ต้องเพิ่มเติมเข้าไปอีกก็พัฒนอีกเป็นครั้งที่ 2 ทำอย่างนี้ไปเรื่อยๆ

3. Formal Systems Development
- การกำหนดคุณสมบัติของระบบ (Specification) ที่ชัดเจน
- มีการวัดผลในเชิงปริมาณ < เป็นตัวเลขชัดเจน >
- เวลาพัฒนาระบบจะทำในลักษณะที่ว่า เมื่อพัฒนาระบบไปถึงจุดหนึ่งก็จะทำการวัดผลว่าได้ตามที่กำหนดไว้จริงหรือเปล่า
ข้อดี : ระบบจะได้งานตรงตาม Requirement และมีข้อผิดพลาดน้อย
ข้อเสีย : สิ้นเปลือง

4. Reuse-based Development
- เป็นระบบที่พยายามออกแบบ SW ออกมาในลักษณะ Object ย่อยๆ แล้ว Object ในการพัฒนาจริงอาจจะไม่ตรงกับ Requirement ที่ได้กำหนดไว้ในตอนแรก เราจะพัฒนาแบบกลางๆเอาไว้เพื่อให้มันมีความยืดหยุ่นสูง เผื่อวันหลังจะใช้งานต่อได้อีก กล่าวคือ เน้นออกแบบมาเป็น Object ที่ใช้ใหม่ได้อีก

Waterfall Model <Slide 5> ประกอบด้วย 5 ขั้นตอน

- Requirement Definition : การกำหนดหรือระบุความต้องการของระบบและคุณสมบัติของความต้องการ
- System and Software Design : ออกแบบระบบ
- Implementation and Unit testing : ลงมือพัฒนาและทำการทดสอบ
- Integration and System testing : เอาแต่ละส่วนย่อยๆมาประกอบรวมกัน
- Operation and Maintenance : ติดตั้งใช้งานจริงและขั้นตอนการบำรุงรักษา โดยที่สามารถย้อนกลับไปทำขั้นตอนเดิมๆได้เมื่อเกิดปัญหา
ข้อดี : เราทำตามขั้นตอนได้ชัดเจน เพราะมีการบ่งบอกว่าแต่ละขั้นตอนต้องทำอะไร และติดตามความคืบหน้าได้ชัดเจน
ข้อเสีย : เมื่อผ่านขั้น Requirement ไปแล้ว และเราไปทำขั้นตอนอื่นๆ จะมายุ่งกับ Requirement อีกไม่ได้แล้วจนกว่าจะจบกระบวนการถึงจะกลับไปทำ Requirement อีกทีได้ ทำให้เสียเวลาสิ้นเปลืองทรัพยากร

Evolutionary Development < Slide 7>

การพัฒนา SW ในลักษณะพัฒนาเป็นวิวัฒนาการไปเรื่อยๆ โดยมีการปรับเปลี่ยน Spec.ไปเรื่อยๆ พัฒนาไป ปรับเปลี่ยน Spec.ไป เป็นลักษณะของ Version

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

จากภาพ จะแบ่งกลุ่มของ Version ออกเป็น 3 กลุ่มคือ

- Initial Version : Version เริ่มต้น โดยส่วนมากจะทำงานตามฟังก์ชันพื้นฐานของ SW
- Intermediate Version : จะมีการเพิ่มการทำงานต่างๆเข้าไป
- Final Version : คือ Version ที่สมบูรณ์แล้ว

ข้อดี : เกิดจากการที่เราค่อยๆทำทีละ Version ทำให้เกิดการขัดเกลา Requirement หลายรอบ ทำให้ requirement มีความผิดพลาดน้อย
ข้อเสีย : บอกความคืบหน้าลำบากว่างานถึงไหนแล้ว กล่าวคือ Check Milestone ได้ค่อนข้างลำบาก

Formal System Development

ไม่ค่อยซับซ้อน เป็นการกำหนดเงื่อนไขที่ค่อนข้างชัดเจน มักจะเป็นเงื่อนไขเชิงปริมาณ เป็นเลขที่วัดได้
ข้อเสีย :
1. ใช้เวลานาน
2. ในการทดสอบโปรแกรมหรือระบบต้องใช้บุคลากรที่มีความชำนาญมาก

Reuse-Oriented Development

โดยที่จะมองได้ 2 ลักษณะ
1. พัฒนา SW ใหม่ล้วนๆเลย โดยพัฒนาเป็นลักษณะ Object เพื่อเอากลับมาใช้ได้ใหม่อีก
2. พัฒนา SW ไม่ทั้งหมด 100% แต่เราหา SW อื่นๆที่พัฒนาแล้วมาเชื่อมกับของเรา โดยที่ในตำราเล่มนี้ใช้คำว่า COTS ( Commercial Off The Shelf ) โดยที่ COTS คือ SWที่ทีมอื่นหรือบริษัทอื่นพัฒนาเสร็จแล้วนำเอมาขาย แล้วเราเห็นว่ามันมีความสามารถตรงกับสิ่งที่เราต้องการ เราก็ซื้อมาเชื่อมกับงานของเรา

จากรูป <Slide13>

- ส่วนการกำหนด Requirement เหมือนเดิมไม่ค่อยมีอะไร
- ส่วนComponent Analysis คือ วิเคราะห์ลักษณะของการแตกเป็น Module หรือ Object ย่อยๆ โดยจะวิเคราะห์ว่า Object ย่อยๆควรจะมีคุณสมบัติอย่างไรเพื่อที่จะให้มันสามารถใช้งานได้หลายรอบ
- ส่วน Requirement Modification : กล่าวคือ เมื่อเรามี Requirement พื้นฐานเรียบร้อยแล้ว เราก็จะเอามาปรับปรุงเพิ่มเติมเข้าไปอีก ตย.เช่น E-Learning โดยระบบที่ดีที่สุดคือ AICC(สอนการบิน) เพราะ AICC มีมาตรฐาน ดังนั้นถ้าพูดถึง E-Learning จะต้องอิงกับมาตรฐานของ AICC จะทำให้งานดี น่าเชื่อถือ เพราฉะนั้นตรงส่วนนี้ส่วนใหญ่จะเป็นการเพิ่ม Requirement เพื่อให้มันมีมาตรฐานมากขึ้น

Process Iteration

การวนลูปพัฒนาซ้ำๆโดยที่ Model แบบที่ 1<2 จะมีการวนลูปซ้ำๆมากกว่าแบบที่ 3,4 แต่โดยสรุปก็มีการวนลูปทั้ง 4 Model นั่นแหละ วิธีการพัฒนาที่ทำซ้ำมี 2 ลักษณะใหญ่ๆคือ
- Incremental Development
- Spiral Development

Incremental Development

จะสอดคล้องกับ Model ต่างๆที่กล่าวไว้เป็นส่วนใหญ่ โดยแนวคิดของ Incremental คือ แทนที่เราจะทำ SW ให้จบทีเดียว เราก็จะทำเป็นทีละส่วนย่อยๆแล้วนำไปทำการทดสอบหรือไม่ก็ส่งงานไปเหมือนกับเป็น Milestone ย่อยๆไป

จากรูป ในขั้นแรก จะเป็นการกำหนด Requirement คร่าวๆ แล้วขั้นต่อมาจะพิจารณาหาส่วนที่จะเพิ่มRequirement เข้าไป หลังจากนั้นก็จะเป็นขั้นตอนการออกแบบให้เห็นภาพรวมของระบบ แล้วจึงมาออกแบบงานชิ้นย่อยชิ้นแรกโดยละเอียดและตรวจสอบ แล้วก็วนกลับมาทำ Increment ที่2 แล้วตรวจสอบ แล้วนำมารวมกับ Increment ที่1 แล้วตรวจสอบภาพรวมว่าทำงานได้เป็นอย่างไร แล้วจึงวนกลับไปทำ Increment ที่3และ Increment ที่เหลือซ้ำอย่างนี้จนจบทุก Increment ที่กำหนดไว้จนได้ออกมาเป็น Product สุดท้าย
ข้อดี :
- Increment แรกๆจะโดนตรวจสอบหลายรอบ เช่น ถ้ากำหนดให้งานมี 10 Increment ใน Increment ที่1จะโดนทดสอบ 10 รอบ Incrementที่2จะโดนทดสอบ 9 รอบ Incrementที่3จะโดนทดสอบ3รอบ
- ถ้า Requirement เปลี่ยนแปลงก็สามารถนำรวมเข้าไปได้เรื่อยๆ

Spiral

แบ่งการพัฒนาเป็น 4 โซน
1. เป็นโซนของการวางแผนสำหรับ Phase ถัดๆไป
2. เป็นโซนที่จะพิจารณาว่าวัตถุประสงค์ของสิ่งที่พัฒนา ณ เวลานั้นมีอะไรบ้าง และมีปัญหาที่จะต้องแก้ไขหรืออุปสรรคอะไรบ้าง
3. เป็นการวิเคราะห์ว่าจะมีความเสี่ยงอะไรบ้าง และสามารถสร้างทางเลือกเพื่อแก้ปัญหาอะไรได้บ้าง
4. ลงมือพัฒนาและทดสอบระบบ

จากรูปจะเริ่มจากส่วน Requirement plan Life-cycle plan แล้วมา Review ว่าสิ่งที่ตั้งใจจะทำมีวัตถุประสงค์อะไรบ้าง มีทางเลือกและอุปสรรคอะไรบ้าง เสร็จแล้วจึงมาวิเคราะห์ความเสี่ยงรอบแรกว่าเราจะเจอปัญหาอะไรที่จุดไหนแล้วตอบรับอย่างไรบ้าง หลังจากนั้นก็จะมาทำ Prototype ที่1 ส่วน Simulation model Benchmark จะเป็นการทดสอบลักษณะเชิงวัดผลว่าที่ทำมานั้นได้ตามเงื่อนไขที่ควรจะเป็นมากน้อยแค่ไหน

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

ขั้นต่อไปเป็นการเก็บและตรวจสอบ Requirement และวนรอบต่อไปทำการออกแบบและพัฒนาระบบ แล้วในรอบต่อไปคือ Integrate , ทดสอบระบบ , ทำ Alpha test และ Beta test จนกระทั่งจบกระบวนการ

ขั้นตอนที่เกี่ยวข้องกับ Requirement < Slide 22 >

1. ศึกษาความเป็นไปได้ - เป็นสิ่งแรกที่ควรจะทำในการพัฒนาระบบหรือ SW ใดๆ ซึ่งจะเป็นการศึกษาว่าคุ้มทุนหรือเปล่าที่จะสร้างหรือสร้างแล้วจะพบกับปัญหาอะไรมากน้อยแค่ไหน
2. เก็บรวบรวมและวิเคราะห์ Requirement - เกิดจากการสัมภาษณ์ผู้บริหารและผู้ปฏิบัติ , ดูเอกสารและแบบฟอร์มต่างๆ , สังเกตจากการทำงานจริง และนำมาวิเคราะห์ได้ออกมาเป็น System model
3. กำหนด Specification – ซึ่งก็จะมีการวนกลับไปมาระหว่างการกำหนด Spec. และเก็บ Req.เพิ่มเติม ได้ออกมาเป็น User Requirement กับ System Requirement เขียนมาเป็นข้อๆชัดเจนว่าต้องการให้ระบบทำอะไรบ้าง
4. ตรวจสอบ Requirement ว่าถูกต้อง,ไม่คลุมเครือ และนำไปให้ผู้บริหารหรือผู้ใช้อ่านอีกครั้งว่าใช่หรือไม่ ซึ่งจะได้ออกมาเป็น Requirement document

และหลังจากเราเสร็จงานเอกสารทุกอย่างทั้งหมดเราจะสรุปเนื้อหาสำคัญจริงๆ 1 หน้ากระดาษเป็น Executive summery เพื่อให้ผู้บริหารอ่าน ซึ่งควรจะวางไว้หน้าแรกของเอกสาร และจึงตามด้วยการศึกษาความเป็นไปได้

กระบวนการออกแบบระบบ < Slide 24 >

จากภาพ หลังจากขั้นตอนของ Requirement Specification จะนำมาเขียนเป็น System architecture ( มักจะเป็น Block diagram ) ซึ่งจะบอกว่าระบบประกอบด้วยส่วนสำคัญอะไรบ้าง มีการเชื่อมโยงกันอย่างไร ต่อมาก็เขียน SW Spec. ( บางเล่มเรียกว่า Functional Specification )บอกว่าความสามารถที่ SW ทำได้มีอะไรบ้าง หลังจากนั้นก็ออกแบบ Interface ได้เป็น Interface Spec. ( ซึ่ง Interface Spec. กับ SW Spec.จะไม่เหมือนกันโดยที่ SW Spec. จะเน้นว่าทำอะไรได้บ้าง เช่น SW สำหรับให้พนักงานธนาคารที่เคาน์เตอร์ SW Spec.จะต้องบอกว่าเขาจะสามารถคีย์ข้อมูลการเบิกเงิน ,การถอนเงิน ,การฝากเงิน , การโอนเงิน และพิมพ์สมุดบัญชีได้ แต่ Interface Spec.จะเป็นรายละเอียดของ Interface โดยเฉพาะ เช่นลักษณะหน้าจอเป็นยังไง ใช้อุปกรณ์อะไรเป็น Input ตรงส่วนไหนใช้เมาส์ตรงไหนใช้คีย์บอร์ดและกดปุ่มไหนทำอะไรบ้าง ) ต่อไปเป็นการทำ Component Spec. เป็นการแบ่งระบบทั้งหมดออกเป็นระบบย่อยๆว่าส่วนไหนทำอะไรบ้าง มีฟังก์ชันอะไรบ้าง เสร็จแล้วก็จะเป็นส่วนของ Data ว่ามีการจัดเก็บข้อมูลอย่างไร , Database ออกแบบมาในลักษณะไหนใช้ DBMS หรือ File ,เชื่อมโยงกันอย่างไร

สุดท้ายเป็นการออกแบบระบบ Algorithm ซึ่งก็คือลำดับขั้นการทำงานของโปรแกรม เช่นเคาน์เตอร์ธนาคารมีลูกค้าต้องการจะโอนเงินจากบัญชี A ไปยังบัญชี B จำนวน 500 บาท Algorithm คือ 1.ตรวจสอบว่าบัญชี A มีเงินมากกว่า 500 หรือไม่ ถ้ามากกว่าถึงจะโอนได้แต่ถ้าน้อยกว่าก็ต้องปฏิเสธว่าโอนไม่ได้ 2.ตรวจสอบบัญชี B ว่ามีตัวตนอยู่จริงหรือเปล่าและ Active อยู่หรือเปล่าไม่ได้ถูกอาหยัดหรือมีปัญหาอยู่ 3.ถอนเงินจากบัญชี A 500 บาท 4.ฝากเงิน 500 บาทลงในบัญชี B

ขั้นตอนการตรวจสอบ < Slide 27>

แบ่งออกเป็น 3 ส่วนใหญ่ๆ
1. ทดสอบแต่ละ Component
2. ทดสอบการนำ Component มารวมเข้าด้วยกัน
3. ให้ User ทดสอบใช้งานจริง

Unit test : เป็นการทดสอบในระดับ Unit ว่าฟังก์ชันนั้นถูกกำหนดว่าจะรับ Input อะไรและได้ Output อะไรออกมา เช่น ฟังก์ชันหนึ่งทำงานกับตัวเลขในช่วง –10 ถึง +10 การทดสอบเราควรจะเอาตัวเลขที่ทดสอบทั้งที่อยู่ในช่วงและนอกช่วง ได้แก่ –10 , +10 , 0 , 0 ถึง –10 ,0 ถึง –5 , -100, +15 ,ตัวอักษร ,สัญลักษณ์ , เครื่องหมาย ,ค่าว่าง

Module test : ในหลายๆ Unit จะประกอบเป็น 1 Module ( เช่นในภาษาC Main Function จะเป็น 1 Module ) เป็นการทดสอบภาพรวม ส่วนใหญ่Logic ,Concept หรือ Business rule มักจะอยู่ในส่วน Module (แต่ใน Unit test ส่วนใหญ่จะเป็นการบวกลบคูณหาร )

Sub-system test : เป็นการทดสอบระบบย่อย เช่น ระบบสาขาธนาคารอาจแบ่งออกเป็น3ส่วนคือ ระบบรับเรื่องหน้าเคาน์เตอร์ , ระบบสรุปยอดบัญชีรายวัน , ระบบATM

System test : เป็นการทดสอบทั้งระบบ หลังจากรวม Sub-system เข้าด้วยกัน

Acception test : ให้ User ทดสอบใช้ , มักเป็นการทดสอบ Interface
- Alpha test มักจะอยู่ในส่วนทางซ้ายตั้งแต่ Unit test และจบลงที่ System test ซึ่งเป็นการทดสอบที่ผู้พัฒนาได้ทำการทดสอบในสถานที่ของผู้พัฒนาเอง และอยู่ในกรอบของ Requirement
- Beta test จะเป็นในส่วนของ Acception test คือให้ User ได้ใช้งานจริงและรายงานออกมาว่าเป็นอย่างไรบ้าง

บางครั้ง Business rule หรือว่า Concept ต่างๆจะตกอยู่ในส่วนของ Beta test ด้วย เพราะผู้พัฒนาเป็นผู้ทดสอบในส่วน Alpha test ซึ่งจะไม่ชำนาญในส่วน Business rule ( แต่ Business rule จะอยู่ใน Requirement และปผู้พัฒนาก็ทดสอบตาม Requirement ที่กำหนดไว้แต่ก็อาจจะยังยัง Business rule บางอย่างที่ไม่เป็นไปตามที่ User ต้องการ )

การเลือกว่าจะใช้ลักษณะวิธีไหนในการทดสอบขึ้นอยู่กับว่าความเหมาะสมของ SW ว่าใหญ่แค่ไหน ต้องการความละเอียดแค่ไหน

System Evolution

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

Case Tool (อ.ไม่ได้พูดซ้ำเพราะเคยพูดไปแล้ว)

บรรยายเมื่อ : 24 ธค. 2544