Sw evo 2_model

Process Model
แบบจำ ลองกระบวนกำรพฒันำ/ผลิตซอฟต์แวร์ (Process Model)
แบบจำ ลองใช้สำ หรบัชี้นำถึงกิจกรรมหลกั (key Activities) ในกำรพฒันำซอฟต์แวร์
ด้วยกำรกำหนดรำยละเอียดหรือข้อบัญญตัิไว้ในแต่ละกิจกรรมในแต่ละข้นัตอนที่มี
ลำดบัข้นัตอนกำรพฒันำที่ชดัเจน เพื่อต้องกำรให้กำรพฒันำซอฟต์แวร์ดำเนินต่อไป
โดยเกิดปัญหำน้อยที่สุด ปัจจุบนัมีกำรคิดค้นแบบจำ ลองต่ำง ๆ ให้เลือกใช้งำนมำกมำย
ส่วนกำรตดัสินใจว่ำจะเลือกใช้แบบจำ ลองใดขึ้นอยู่กบัปัจจยัหลำยอย่ำง เช่น ขนำดของ
โครงกำร ควำมเหมำะสม และระดบัควำมเสี่ยง เป็นต้น
สำเหตุสำ คญัที่จำ เป็นต้องใช้แบบจำ ลองกำรพฒันำซอฟตแ์วร์ เพรำะ
1. แบบจำ ลองพฒันำซอฟต์แวร์จะมีกำรแตกข้นัตอนของกระบวนกำรพฒันำในแต่
ละเฟส (phase)
2. ซอฟต์แวร์ที่พฒันำมีควำมซบัซ้อน
3. กำรแบ่งเป็นกระบวนกำรพฒันำเป็นเฟสหรือระยะ จะทำ ให้ง่ำยต่อกำรจดักำร
4. แต่ละเฟสมีแนวทำงต่ำง ๆ ให้เลือกปฏิบตัิ
Asst.Prof.Paijit Suksomboon SoftwareEvolution 2 / 1 LPRU

Process Model
แบบจำ ลองพฒันำซอฟต์แวร์ที่สำ คญั
แบบจำ ลองมกัผนวกกระบวนกำรในลกัษณะ กำรทวนซำ้เป็นรอบ (Iteration) กำรพฒันำ
แบบก้ำวหน้ำ (Incremental) และกำรจัดทำต้นแบบ (Prototyping) ซึ่งเป็น
กระบวนกำรลดควำมเสี่ยงในกรณีซอฟต์แวร์มีกำรเปลี่ยนแปลงในควำมต้องกำรอยู่
ตลอดเวลำ แบบจำ ลองที่สำ คญัและนิยมนำมำใช้ในกำรพฒันำได้แก่
- Waterfall Model : แบบจำลองน้ำตก
- Incremental Model : แบบจำ ลองค่อยๆ สร้ำงเพมิ่
- RAD Model : แบบจำลองอำร์เอดี
- Prototype Model : แบบจำลองต้นแบบ
- Spiral Model : แบบจำลองวนก้นหอย/เวียนวน
- Agile Model

Process Model
Waterfall Model (แบบจำลองน้ำตก)
 เผยแพร่ในปี ค.ศ.1970 เป็นวิธีกำรที่ได้รบักำรพฒันำขึ้นมำต้งัแต่
แรกเรมิ่ที่มีกระบวนกำร พฒันำซอฟต์แวร์บำงคร้งัเรียกว่ำ วงจรชีวิต
แบบคลำสิก (classic life cycle) ตำมแนวทำง SDLC
 แบ่งกระบวนกำรทำ งำนออกเป็นข้นัตอนต่ำง ๆ ตำมลำ ดบัจึงเรียก
ลกัษณะของแบบจำ ลองว่ำ Sequential Model
 ข้นัตอนในแต่ละช่วงจะสืบเนื่องกนัไปจำกข้นัหนึ่งสู่อีกข้นัหนึ่ง
ตำมลำ ดบัเหมือนสำยน้ำตก
 สำมำรถย้อนกลบัไปปรบัปรุงข้นัตอนก่อนหน้ำได้ตำมลำ ดบัโดยเพมิ่
คุณสมบตัิกำรทวนซำ้เป็นรอบ (Iteration)
 แนวทำงนี้ผู้ใช้จะเห็นระบบใหม่ก็ต่อเมื่อโครงกำรเสร็จสิ้น

Process Model
แบบจำลองน้ำตก (Waterfall Model)

Process Model
แบบจำ ลองน้ำตกแบบ
ดดัแปลง (Adapt
Waterfall)

Process Model
 Requirements analysis and definition
- กำรวิเครำะห์และให้คำ จำ กดัควำมของระบบงำน
 System and software design
- ในกำรออกแบบระบบ ผู้ออกแบบต้องคำ นึงถึงโครงสร้ำงของ
ฮำร์ดแวร์และซอฟตแ์วร์ที่จำ เป็นต้องพฒันำ
- ในกำรออกแบบซอฟต์แวร์เป็นกำรกำ หนดโครงสร้ำงหลกัของกำร
โปรแกรมที่จะพฒันำ
 Implementation and unit testing
– กำรกำ หนดสร้ำงและทดสอบหน่วยย่อย
– เป็นกำรแบ่งส่วนของซอฟต์แวร์ออกเป็นหน่วยย่อย ๆ
– ทำ กำรตรวจสอบควำมถูกต้องหลงัจำกเขียนโปรแกรมเสร็จสนิ้

Process Model
 Integration and system testing
- กำรเช่อืมโยงและทดสอบท้งัระบบ
- ทำ กำรตรวจสอบหลงัจำกนำโปรแกรมย่อยในแต่ละส่วนมำรวมกนั
 Operation and maintenance
- กำรติดต้งัใช้งำนและกำรบำ รุงรกัษำ
- เป็นข้นัตอนที่ใช้เวลำนำนที่สุด
- ข้นัตอนในกำรแก้ไขข้อผิดพลำด กำรปรบัแต่ง

Process Model
 ข้อดี
- แบ่งงำนยำกให้เป็นงำนที่เล็ก งำนต่อกำรจดักำร
- มีกำรกำ หนด product ที่ต้องส่งมอบในแต่ละงำนอย่ำงชดัเจน
- Simple, step-by-step, focused, and easy to follow..
 ข้อเสีย
- ถ้ำ ค้นพบข้อผิดพลำดของข้นัที่เสร็จสนิ้แล้ว ไม่สำมำรถแก้ไขได้
กำรแก้ไขจำ เป็นต้องเรมิ่รอบ (Iteration) ใหม่ ซึ่งในควำมเป็นจริง
หลงักำรทำ งำนในแต่ละข้นัควรสำมำรถย้อนไปแก้ไขควำมผิด-
พลำดในข้นัใดใดก็ได้ก่อนหน้ำ
- ดงัน้นัในทำงปฏิบตัิข้นัตอนกำรทำ งำนในWaterfall จึงไม่เป็นเชิง
เส้น (Linear)
- ข้อเสียหลกัคือ ลูกค้ำเห็นและทดลองใช้Software ก็ต่อเมื่อถึงข้นั-
ตอนสุดท้ำย หำกมีบำงอย่ำงที่ไม่ตรงกบัควำมต้องกำรของลูกค้ำ
กำรแก้ไขยำก แพง เสียเวลำ

Process Model
แบบจำ ลองค่อย ๆ สร้ำงเพมิ่ (Incremental Model)
เป็นแบบจำ ลองที่มีส่วนผสมของ Waterfall model กบักำรทำ ซำ้ลกัษณะ
ลูป (Loop) จะเห็นว่ำแบบจำ ลองนี้จะมีลำ ดบัเชิงเส้นแบบวนซำ้หลำยรอบ
โดยวำงให้เหลื่อมกันตำมเวลำปฏิทิน โดยขจัดข้อเสียของ Waterfall
Model ที่มีกระบวนกำรทดสอบอยู่ตอนท้ำย ๆ แต่ Incremental Model
จะพฒันำแบบทวนซำ้เป็นรอบพร้อมกบัมีระบบตรวจสอบ
Verification : Are we building the product right ?
กำรตรวจสอบควำมถูกต้องตำมข้อกำหนด (Specification) หรือ
พยำยำมค้นหำข้อผิดพลำดจำกกำรประมวลผลโปรแกรม
Validation : Are we building the right product ?
ตรวจสอบรำยละเอียดของผลิตภณัฑ์ว่ำตรงตำมควำมต้องกำรของ
ผู้ใช้หรือไม่

Process Model
เรำจะแบ่งงำนออกเป็นงำนย่อยๆ และเรียกงำนย่อยๆ นั้นว่ำ Increment แล้วจึงค่อยพฒันำงำนให้สำ เร็จไปเป็น
แต่ละ Increment ไป โดยเรำจะทำกำรพฒันำงำนที่เป็นแกนของโครงกำรก่อน แล้วค่อยพฒันำ Increment
ย่อยอื่นๆ ตำมควำมสำ คญัของงำน ไปจนจบโครงกำร ซึ่งกำรพฒันำในแต่ละ Increment จะต้องมีกำรตรวจสอบ
และยอมรบัจำก customer
1st Increment
analysis design coding testing delivery
2nd Increment
3rd Increment
4th Increment
Project
Definition

Process Model
แบบจำลองแบบค่อยๆสร้ำงเพมิ่ มีลกัษณะคล้ำยกบัแบบวิวฒันำกำร ต่ำงกนัที่ระบบที่สร้ำงได้ใน
ตอนแรกยงัไม่ใช่ระบบที่สมบูรณ์ แต่เป็นส่วนหนึ่งของท้งัหมด จะต้องเพมิ่ส่วนอื่นๆไปเรื่อยจนได้
ระบบที่สมบูรณ์ในช่วงรอบแรกๆน้นัเก็บข้อมูลแค่คร่ำวๆ แล้วค่อยรื้อปรบัปรุงในรอบหลงัๆ

Process Model
แบบจำ ลองค่อย ๆ สร้ำงเพมิ่ (Incremental Model)
แต่โครงกำรที่จะใช้กำรพฒันำแบบ incremental ได้ จะต้องเป็นโครงกำรที่ มีกำรเปล่ยีน
แปลงของ requirement ไม่มำก ซึ่งกำรเปลี่ยนแปลงจะต้องไม่กระทบต่อ Increment ที่
ได้ทำ กำรพฒันำและส่งมอบไปแล้ว และเป็นโครงกำรที่ใช้เวลำไม่นำนมำกนกั
- กำรพฒันำซอฟต์แวร์ทำ ได้อย่ำงรวดเร็วโดยดำ เนินงำนระหว่ำงวงจรซอฟต์แวร์
- มีควำมยืดหยุ่นสูง ค่ำใช้จ่ำยน้อยในกำรเปลี่ยนแปลงขอบเขตหรือควำมต้องกำร
- ตรวจสอบข้อผิดพลำดได้ง่ำยและจดักำรควำมเสี่ยงได้ง่ำยเพรำะควำมเสี่ยงของ
ชนิ้งำนถูกกำ หนดและจดักำรขณะที่ทำ ซำ้
- ส่งมอบงำนได้เร็ว ลดอตัรำเสี่ยงของกำรเลิกจ้ำง
- นกัวิศวกรและ customer สำมำรถมองเห็นควำมก้ำวหน้ำของโครงกำรได้
- ระหว่ำงรอบกำรผลิตซำ้ต้องเข้มงวดและตรวจสอบไม่ให้เกิดกำรทบัซ้อนกนั
- ปัญหำอำจจะปรำกฏในโครงสร้ำงทำงสถำปัตยกรรมของระบบได้ เพรำะว่ำ ควำม
ต้องกำรบำงส่วนอำจไม่ได้ถูกรวมไว้ต้งัแต่เรมิ่ก่อนเข้ำมำในวงจรของกำรพฒันำ
ซอฟต์แวร์
p r o j e c t c a le n d a r t im e
 ข้อดี

Process Model
จำกแบบจำ ลองกำรพฒันำซอฟต์แวร์ท้งัแบบ Waterfall และ Incremental อำจ
ทำ ให้สบัสนระหว่ำงคำ ว่ำ Iteration และ Incremental จึงสรุปได้ดงันี้
 กำรทวนซำ้เป็นรอบ (Iteration)
คือ กำรทวนซ้ำ ของงำน ซึ่งมีควำมเป็นไปได้ว่ำ กำรพฒันำงำนใด ๆ อำจมี
ควำมจำ เป็นต้องมีกำรทวนซ้ำ ของงำนมำกกว่ำหนึ่งรอบ เพื่อให้งำนตรงกบั
ควำมต้องกำรมำกที่สุด กำรทวนซ้ำมำกกว่ำหนึ่งรอบถือเป็นกำรทบทวน
ควำมถูกต้องและลดควำมเสี่ยง
 กำรพฒันำแบบก้ำวหน้ำ (Incremental)
คือ วิธีกำรพฒันำส่วนย่อยของระบบให้สมบูรณ์ โดยแต่ละระบบย่อยหรือ
แต่ละส่วนที่พฒันำนั้นอำจมีจำนวนกำรทวนซ้ำหลำยรอบ จำกนั้นก็ทำ กำร
เพมิ่ระดบัควำมก้ำวหน้ำในส่วนงำนที่ทำ เสร็จ และท้ำยสุดก็จะนำส่วนงำน
ย่อยที่เสร็จสมบูรณ์เหล่ำน้นัมำประกอบรวมกนั ให้เป็นหนึ่งระบบที่สมบรูณ์
p r o j e c t c a le n d a r t im e

Process Model
แบบจำลองอำร์เอดี (RAD Model)
RAD (Rapid Application Development) เป็นแบบจำลองกระบวนกำร
ซอฟต์แวร์แบบค่อยเพิ่มขึ้นที่เน้นวงจรพัฒนำสั้น ๆ เพื่อกำรพัฒนำ
แอพพลิเคช่นัอย่ำงรวดเร็ว เป็นกำรดดัแปลงจำก Waterfall Model โดยนำ
วิธีกำรประกอบคอมโพเนนท์ย่อยเข้ำด้วยกนั โดยมุ่งเน้นด้ำนกำรลดต้นทุนและ
ระยะเวลำในกำรพัฒนำ เพื่อควำมคล่องตวัจึงจำเป็นต้องมีทีมงำนที่มีควำมรู้
ควำมสำมำรถเฉพำะ เช่น ผู้เชี่ยวชำญด้ำนเทคโนโลยีสำรสนเทศกับกลุ่ม
ผู้ใช้งำนมำร่วมกนัพฒันำ เป็นต้น
เทคนิคสำ คญัในกำรพฒันำซอฟตแ์วร์แบบ RAD
1. พฒันำต้นแบบได้อย่ำงรวดเร็ว
2. เป็นแหล่งรวบรวมเครื่องมือเพ่อืกำรพฒันำแอปพลิเคชนั
3. มีทีมงำนที่เชี่ยวชำญกำรใช้เครื่องมือเหล่ำน้นั
4. มีกรอบระยะเวลำกำรพฒันำที่จำ กดั
5. มีแนวปฏิบตัิแบบพฒันำแอปพลิเคช่นัแบบร่วมกนั

Process Model
Communicat ion
Planning
Team#n
Modeling
business modeling
datamodeling
process modeling
Team# 2
Model ing
business modeling
dat a modeling
process modeling
Team# 1
Modeling
business modeling
dat a modeling
process modeling
Const ruct ion
component reuse
automatic code
generation
testing
Const ruct ion
component reuse
aut omat ic code
generat ion
t est ing
Const ruct ion
component reuse
aut omat ic code
generat ion
t est ing
Deployment
60 - 90 days
int egrat ion
delivery
feedback

Process Model
ข้อดี
- ใช้เวลำในกำรพฒันำส้นั
- ลดค่ำใช้จ่ำยเพรำะใช้หลกักำรนำกลบัมำใช้ใหม่ และสร้ำงแบบแบ่งส่วนประกอบ
ย่อย ๆ
ข้อเสีย
- โครงกำรส่วนใหญ่ที่ใช้วิธีนี้ จำ เป็นต้องมีทรพัยำกรบุคคลจำ นวนมำกเพื่อ
แบ่งเป็นทีมหลำย ๆ ทีมยกเว้นโครงกำรที่ไม่สำมำรถขยำยส่วนได้
- โครงกำรอำจล้มเหลวได้โดยง่ำย ถ้ำนกัพฒันำและลูกค้ำไม่ทำ ตำมกิจกรรมที่
จำ เป็นสำ หรบักำรพฒันำอย่ำงรวดเร็ว
- ระบบที่ไม่สำมำรถแบ่งเป็นโมดูลได้ จะมีปัญหำในกำรสร้ำงคอมโพเนนท์ที่จะใช้
- ถ้ำระบบต้องกำรประสิทธิภำพสูง ๆ โดยกำรปรบัแต่งส่วนเชื่อมต่อคอมโพเนนท์
วิธีกำรนี้อำจไม่ได้ผล
- อำจไม่เหมำะสมกบัระบบที่มีควำมเสี่ยงด้ำนเทคนิคสูง และเกี่ยวข้องกบั
เทคโนโลยีใหม่ ๆ

Process Model
แบบจำ ลองกระบวนกำรเชิงวิวฒัน์ (Evolutionary Process Model)
ซอฟต์แวร์จะมีวิวฒันำกำรตำมกำลเวลำที่ผ่ำนไป ควำมต้องกำรผลิตภณัฑ์และธุรกิจ
มักเปลี่ยนแปลงไปเพื่อพัฒนำก้ำวหน้ำขึ้น ดังนั้นเมื่อกำรพัฒนำไม่สอดคล้องกับ
กำรตลำดจึงทำ ให้เกิดซอฟต์แวร์ที่ไม่สมบูรณ์ 100% แต่มกัจะออกเวอร์ชั่นที่ทำ งำน
อย่ำงจำกดัออกมำก่อน และขยำยกำรทำ งำนต่อไปเรื่อย ๆ ซอฟต์แวร์เวอร์ชั่นหลงั ๆ
จะมีควำมสมบูรณ์เพมิ่มำกขนิ้ ดงัเช่น แบบจำ ลองหลกั 2 รูปแบบ ต่อไปนี้
 แบบจำลองต้นแบบ (Prototyping Model)
 แบบจำ ลองสไปรลั (Spiral Model)

Process Model
แบบจำลองต้นแบบ (Prototyping Model)
Communi-cation
Quick
plan
Deployment
delivery &
Feedback
Modeling
Quick design
Construction
of prototype
- step 1: Requirements gathering
-step 2: A “quick design” -> focuses on
visible functions and behaviors of
the product
- step 3: Prototype construction
- step 4: Customer evaluation of the prototype
loop back step 1.
บ่อยคร้งัที่ลูกค้ำมกับอกเป้ำหมำยท่วัไปของซอฟต์แวร์
โดยไม่ระบุรำยละเอียดด้ำน Input-Process-
Output ที่ต้องกำร ซึ่งทำ ให้ผู้พฒันำไม่ม่นัใจในกำร
เลือกใช้อลักอริทึ่มหรือโครงกำร ดงัน้นัวิธีกำรที่ดีที่สุด
คือกำรสร้ำงต้นแบบเพื่อช่วยให้นักวิศวกรและลูกค้ำ
ได้เข้ำใจกนัดียิ่งขึ้น

Process Model
แบบจำลองต้นแบบ (Prototyping Model)
 ข้อดี
- ง่ำยและรวดเร็วตำมควำมต้องกำรของลูกค้ำ
- ลูกค้ำสำมำรถตรวจสอบต้นแบบแต่ละข้นัและจดัหำข้อมลูเพมิ่เติมพร้อมผลตอบรบั
- เป็นแนวคิดที่ดี ถ้ำพบกรณีดงันี้
 ลูกค้ำไม่สำมำรถหำกำหนดควำมต้องกำรโดยละเอียดได้
 มีควำมยุ่งยำกในกำรส่อืสำรเร่อืงระบบกบัลูกค้ำ
 มีกำรใช้เทคโนโลยี, ฮำร์ดแวร์ และอลักอริทึ่มใหม่ ๆ
 เป็นกำรพฒันำจุดหลกัของแอพพลิช่นัระบบ
- ลูกค้ำสมัผสักบัต้นแบบโดยไม่ทรำบว่ำสร้ำงมำอย่ำงหยำบ ๆ และหำกมีกำร
ปรบัปรงุบำ รงุรกัษำให้เกิดควำมสมบรูณ์ลกูค้ำอำจไม่เข้ำใจ
- ลูกค้ำบำงคร้งัอำจกงัวลว่ำต้นแบบไม่ใช่ซอฟต์แวร์ที่ใช้งำนได้จริง
- ผู้พฒันำต้องระลึกอยู่เสมอว่ำต้นแบบ คือ ระบบเบอื้งต้น เคร่อืงมอืหรืออลักอรึทมิ่ที่
ใช้นำมำอย่ำงง่ำย ๆ เพื่อนำเสนอ ห้ำมยึดติดเพรำะเครื่องมือเหล่ำนี้อำจไม่
เหมำะสมกนัสถำนกำรณ์จริง

Process Model
แบบจำ ลองสไปรลั (Spiral Model)
แบบจำ ลองสไปรลัเกิดจำกกำรวิจยัของ Barry Boehm (1988) เป็นแบบจำ ลองที่รวมลกัษณะกำร
วนซำ้ของกำรสร้ำงต้นแบบกบักำรทำ งำนอย่ำงเป็นข้นัตอน และมีกำรควบคุมของแบบจำ ลองน้ำตก
เข้ำด้วยกนั
วิธีกำรพฒันำแบบ "วนเวียน" (spiral model) นี้จะวนเวียนอยู่ระหว่ำงงำน 4 ข้นัตอน
1. กำรวิเครำะห์ควำมต้องกำร (Requirement Analysis)
2. กำรวิเครำะห์ควำมเสี่ยง (Risk Analysis)
3. กำรออกแบบต้นแบบ (Design Prototype)
4. กำรพฒันำต้นแบบและนำมำประกอบรวมกนั (Develop and Integrate Prototype)
วิธีนี้จะเน้นเรื่องกำรวิเครำะห์ควำมเสี่ยงในช่วงที่ 2 ซึ่งกำรวิเครำะห์ควำมเสี่ยง (risk-analysis)
เป็นกำรวิเครำะห์ว่ำ ในกำรพัฒนำซอฟต์แวร์มีปัญหำอะไรบ้ำง แต่ละปัญหำอำจส่งผลกระทบ
รุนแรงในระดบัใด และมีโอกำสเกิดขึ้นได้มำกเพียงใด แล้วรีบจดักำรกบัปัญหำที่มีโอกำสเกิดขึ้น
และมีผลกระทบสูงก่อน ปัญหำดงักล่ำวไม่จำเป็นว่ำจะต้องเป็นปัญหำทำงด้ำนเทคนิค แต่อำจจะ
เป็นปัญหำในกำรบริหำรงำนโครงกำร ปัญหำเรื่องคน ฯลฯ เพื่อให้โครงกำรประสบควำมสำเร็จได้
มำกขึ้น ตวัอย่ำงเช่น หวัหน้ำโครงกำรกำ ลงัคิดจะลำอออก ซึ่งถ้ำลำออกจริง โครงกำรก็จะล้มเหลว
กำรเจรจำกบัหวัหน้ำโครงกำรจึงเป็นเรื่องเร่งด่วนกว่ำเรื่องเทคนิคท้งัหมด

Process Model

Process Model
ขอบเขตกำรทำ งำน:
- The customer communication task
เพื่อให้กำรปฏิสมัพนัธ์ที่ดีและให้ผลลพัธ์ที่ตรงตำมควำมต้องกำรระหว่ำงลูกค้ำและผู้พฒันำ
- The planning task
เพื่อวำงแผนและกำ หนดทรพัยำกร เวลำ และข้อมูลสำรสนเทศอื่น ๆ ที่เกี่ยวข้องกบัโครงงำน
- The risk analysis task
เพื่อประกนัคุณภำพควำมเสี่ยงเชิงเทคนิคและกำรจดักำร
- The engineering task
เพื่อผลิตงำนนำเสนอตวัแอพพลิเคช่นัของระบบให้แก่ลูกค้ำหรือผู้พฒันำเพื่อให้เกิดควำมเข้ำใจ
ร่วมกนั
- The construction and release task
เพื่อสร้ำง ทดสอบ ติดต้งัและ จดัหำเคร่อืงสนบัสนุนกำรใช้งำนแก่ลูกค้ำ หรือผู้ใช้งำน
อำทิ เอกสำรคู่มือ และฝึกกำรอบรม เป็นต้น
- The customer evaluation task
เพื่อให้ได้ผลตอบรบัของลูกค้ำที่จะนำมำทำ ให้เกิดวิวฒันำกำรของสร้ำงผลิตภณัฑ์ขณะที่อยู่ใน
สถำนะดำ เนินงำน และได้ผลตอบรบัด้ำนพฒันำขณะที่กำ ลงัอยู่ในสถำนะติดต้งั

Process Model
 ข้อดี
- ใช้กำรวิเครำะห์ควำมเสี่ยงจำนวนมำกสูง
- ดีต่อโครงกำรที่มีขนำดใหญ่และมีควำมเสี่ยงสูง
- ซอฟต์แวร์จะถูกผลิตภำยในช่วงวงจรกำรพฒันำ
- เสียค่ำใช้จ่ำยสูงในกำรทำแบบจำลอง
- กำรวิเครำะห์ควำมเสี่ยงต้องกำรบุคลำกรที่มีควำมเชี่ยวชำญ
- ควำมสำ เร็จของผลิตภณัฑ์ขึ้นอยู่กบัช่วงกำรวิเครำะห์ควำมเสี่ยง หำกควำมเสี่ยง
สำ คญัไม่ถูกค้นพบ อำจเกิดปัญหำขึ้นในภำยหลงัได้
- ไม่เหมำะในกำรนำไปใช้กบัโครงกำรที่มขีนำดเล็ก

Process Model
สรปุแบบจำ ลองกระบวนกำรเชิงวิวฒัน์
จุดอ่อนของแบบจำลองกลุ่มนี้
(1) กำรพฒันำซอฟต์แวร์ตำมแบบกระบวนกำรนี้ สร้ำงปัญหำในกำรวำงแผนโครงกำร
เพรำะควำมไม่แน่นอนของจำ นวนกำรทำ ซ้ำ เพรำะผู้บริหำรที่วำงแผนโครงกำรมกั
มองเวลำในลกัษณะเชิงเส้น เรมิ่เมื่อไหร่ สนิ้สุดเมื่อไหร่ จึงมกัขดัแย้งกนั
(2) กระบวนกำรนี้ไม่ได้กำ หนดควำมเร็วของวิวฒันำกำรซอฟต์แวร์ ถ้ำวิวฒันำกำรของ
ซอฟต์แวร์เกิดขึ้นเร็วโดยไม่มีช่วงพกั กระบวนกำรจะยุ่งเหยิง สบัสน โดยเฉพำะ
ผู้ใช้งำน แต่ถ้ำเกิดขึ้นช้ำก็จะกระทบกบัควำมสำมำรถในกำรผลิต โดยเฉพำะทีม
พฒันำ
(3) กระบวนกำรนี้ควรเน้นที่ควำมยืดหยุ่น และควำมสำมำรถในกำรขยำยตวัมำกกว่ำ
คุณภำพที่สูง ดงัคำ กล่ำวที่ว่ำ “เรำควรให้ควำมสำ คญักบักำรพฒันำให้เสร็จทนัเวลำ
ก่อนที่โอกำสทำงกำรตลำดจะหมดไป มำกกว่ำ ไปพัฒนำซอฟต์แวร์ที่ไม่มี
จุดบกพร่องเลย”

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

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

Agile
วตัถปุระสงค์ของ Agile
1. เน้นว่ำใครถนัดอะไร และกำรพูดคุยสื่อสำรกนั มำกกว่ำ กำรยึดติดที่เครื่องมือ
และกระบวนกำร เช่นเปลี่ยนให้โปรแกรมเมอร์ไปคุยกบัลูกค้ำแทน ลูกค้ำบอก
อะไรมำก็ทำ ตำมน้นัได้เลย
2. ให้ทำงำนโดยยึดที่ผลผลิต หรือ Software เป็นหลกั เช่น เดิมเน้นเอกสำรแต่
Agile ไม่สนมำกนกั แต่สนที่ว่ำเรำมี Software หรือของส่งให้ลูกค้ำหรือยงั
3. ให้ควำมสำ คญัเรื่องของกำรติดต่อสื่อสำร เช่น เดิมมีสญัญำหรือ contact กนัแต่
Agile ไม่สนใจ ให้มองที่ควำมสมัพนัธ์ระหว่ำงผู้พฒันำกบัลูกค้ำ
4. ยอมรบัควำมเปลี่ยนแปลง เช่น เดิมต้องวำงแผนให้ครบเป็นอย่ำงดี และทำ ตำม
แผน (gantt chart) ให้ได้ แต่ Agile ไม่ต้องทำตำมแผนแต่เน้นกำรสนองควำม
เปลี่ยนแปลงที่เกิดขึ้นได้
หมำยเหตุ: ถ้ำเรำมีโปรเจคเก่ำที่สำมำรถต่อเนื่องได้ ดงัน้นัแสดงว่ำเรำมี Asset เดิมเพื่อมำต้งัต้นทำ
โปรเจคใหม่ เพรำะฉะน้นังำนใหม่เรำก็สำมำรถนำ Asset มำส่งมอบไปก่อนก็ได้

หลกักำรของ Agile
หลกักำรของ Agile บญัญตัิเอำไว้ 12 ข้อชดัเจนดงันี้
1. เป้ำหมำยที่สำ คญัที่สุดคือกำรสร้ำงควำมพึงพอใจให้กบัลกูค้ำด้วยกำรส่งมอบผลิตภณัฑ์
คุณภำพอย่ำงรวดเร็วและต่อเนื่อง
2. ต้อนรับกำรเปลี่ยนแปลงควำมต้องกำรแม้ว่ำจะอยู่ในช่วงปลำยของกำรพัฒนำ
กระบวนกำรควบคุมกำรเปลี่ยนแปลงเพื่อให้ได้มำซึ่งข้อได้เปรียบทำงกำรแข่งขัน
สำ หรบัลูกค้ำ
3. ส่งมอบซอฟต์แวร์ที่ทำงำนได้อย่ำงต่อเนื่อง จำกจำนวน 2-3 สปัดำห์ไปจนถึง 2-3
เดือน โดยมุ่งหวงัจะลดช่วงเวลำเหล่ำนี้ลง
4. ผู้ที่ทำ งำนเชิงธุรกิจและทีนมพฒันำจะต้องทำ งำนด้วยกนัเป็นรำยวนัตลอดโครงกำร
5. สร้ำงควำมกระตือรือร้นให้กบับุคคล จดัสภำพแวดล้อมและกำรสนับสนุนที่ต้องกำร
และไว้ใจว่ำจะทำงำนสำเร็จ
6. วิธีกำรที่มีประสิทธิภำพและประสิทธิผลสูงสุด คือ กำรแลกเปลี่ยนข้อมูลกนัภำยในทีม
พฒันำด้วยกำรสนทนำโดยตรง
7. ซอฟต์แวร์ที่ทำ งำนได้คือข้อมูลหลกัที่ใช้บ่งบอกควำมก้ำวหน้ำ

หลกักำรของ Agile
หลกักำรของ Agile (ต่อ)
8. กระบวนกำรส่งเสริมกำรพฒันำที่ย่งัยืน ผู้สนับสนุน ผู้พฒันำ และผู้ใช้ควรสำมำรถ
ดำ รงไว้ซึ่งก้ำวไปข้ำงหน้ำอนัสม่ำ เสมอไปด้วยกนัอย่ำงไม่มีที่สิ้นสุด
9. กำรให้ควำมสนใจอย่ำงต่อเนื่องต่อควำมสำมำรถทำงเทคนิคและกำรออกแบบที่ดีช่วย
เพมิ่ควำมคล่องตวั
10. ศิลปะของกำรเพมิ่ปริมำณงำนที่ไม่ต้องทำ ให้มำกที่สุดเป็นสงิ่จำ เป็น
11. สถำปัตยกรรม ควำมต้องกำร และกำรออกแบบที่ดีที่สุด มำจำกทีมที่บริหำรตนเองได้
12. ในช่วงเวลำที่เหมำะสม ทีมจะสะท้อนว่ำทำ อย่ำงไรจึงจะมีประสิทธิผลยิ่งขนึ้ ต่อจำกนั้น
จึงปรบัพฤติกรรมให้เหมำะสม
หมำยเหตุ: กำรทำ งำนในข้นัแรก ก็อำจมีกำรส่งมอบของได้เป็น หน้ำจอ, Prototype,
infrastructure โดยข้นัแรกอำจมองว่ำ Progress เรำเท่ำกบั 0 เปอร์เซ็นต์
(เพรำะยงัไม่มีซอฟต์แวร์เกิดข้นั)

 เลือกบำงหลกักำรมำทำ
โมเดลของ Agile
 เป็นวิธีหนึ่งที่จะเอำหลกักำรของ Agile มำจดักำรกบัเอกสำรและระบบเดิม
ที่มีอยู่ได้
 Agile ประกอบด้วย
1) value ผลลพัธ์ 2) principle หลกักำร 3) practices วิธีปฏิบตัิ
 ท้งัสำมอย่ำงนี้เป็นส่วนหนึ่งในโมเดล Agile ที่สำมำรถนำมำพฒันำซอฟต์แวร์
ให้มีประสิทธิภำพและเกิด overhead น้อย
 ให้มอง Agile เป็นส่วนขยำยของกระบวนกำรพฒันำซอฟต์แวร์แบบเดิมได้
o นำ Agile เข้ำไปกำ กบั ดูว่ำของเดิมที่มีอยู่อนัไหนสำ คญัก็ทำ ไม่สำ คญัก็ละ
o นำ Agile มำจดัลำ ดบัควำมสำ คญั ดูว่ำกิจกรรมไหน ควรทำ ไม่ควร

1) Agile Model value
o เน้นติดต่อสื่อสำร
o เน้นควำมง่ำย ไม่ซบัซ้อน
o เน้น feedback จำกลูกค้ำ
o เน้นควำมกล้ำตดัสินใจ
o เน้นควำมเคำรพกนัและกนั
2) Agile Model Core principle
AM Supplement Principle
 ทำให้เป็นมำตรฐำน
 ค่อย ๆ สร้ำงให้มีรูปแบบ เมื่อถึงเวลำค่อยใช้
 โมเดลไม่ใช้ ให้โยนทงิ้ไปเลย เพรำะจะได้ไม่เสียเวลำมำ
o ง่ำย ไม่เวอร์เกิน
o รบั requirement พร้อมเปล่ยีนแปลงได้ตลอดเวลำ
o เน้นปัจจบุนัเป็นหลกั
o ทำ Model ตำมควำมจำ เป็นเท่ำน้นั
ดูแล
o พยำยำมใช้ multiple model มองหลำยๆมุมมอง
o มีกำรตอบกลบัเร็ว
o SW ถือเป็นจดุม่งุหมำยหลกั
o ให้แบกสมัภำระเบำๆ
o เน้น content มำกกว่ำ representation (ที่ใช้
 เน้น contract (สญัญำระหว่ำงระบบที่สมัพนัธ์กนัอยู่)
พยำยำมจดั contract ให้เป็นทำงกำร เช่น web service
มี signatureอะไรบ้ำงใน function call
 กำร update code เฉพำะตอนที่มีปัญหำ
UML เขียน) ไม่เน้นเครื่องมือ เน้นที่เนื้อหำข้ำงใน
o ติดต่อกนัอย่ำงเปิดเผย และตรงไปตรงมำ
o AM Supplement Principle

3) Agile Model Core Practice
1. จดัประชุม รวบรวม Active stakeholder เท่ำน้นั บำงมีอำจมี none-stakeholder เข้ำมำ
ฟังได้ แต่ห้ำมออกควำมคิดเห็น ห้ำมถำม ห้ำมติดต่อ ห้ำมแสดงไอเดีย
2. นำ Artifact มำใช้ให้ถูกต้อง
Note : Artifact คือชนิ้ส่วนของงำนที่เรำทำ ระหว่ำงกำรพฒันำระบบเช่น อีเมลล์, source
code,จดหมำย,ใบเชิญประชุม ถ้ำ Artifact ใดถูกเลือกมำใช้ในกำรทำงำน เรียกว่ำ
"work products" และถ้ำ work products นี้ ถูกส่งมอบให้ลูกค้ำเรียกว่ำ
"Deliverable"
3. พยำยำมให้ทุกคนเป็นเจ้ำของงำน สำมำรถทำ งำนแทนกนัและกนัได้
4. พยำยำมใช้โมเดลแบบคู่ขนำน จะได้มองต่ำงมุม เพื่อเก็บรำยละเอียดของระบบให้ครบ
5. ทำให้เนื้อหำง่ำย
6. พยำยำมวำดรูปไม่ให้ซบัซ้อน
7. พยำยำมให้โมเดลเข้ำถึงได้ทุกคน
8. สำมำรถเปลี่ยน Artifact หนึ่งไปอีกอนัได้
9. ใช้โมเดลแบบเล็กก่อนค่อยขยำย
10. พยำยำมให้ผู้อื่นมีส่วนร่วมในกำรทำโมเดล
11. พิสูจน์ด้วยกำรลองเขียน code ดู (จำก code เรมิ่ต้นต้งัแต่แรก)
12. ใช้เครื่องมือง่ำยๆในกำรทำงำน เช่น กระดำษ,กระดำนดำ

เทคนิคกำรพฒันำแบบ Agile
 Agile model driven development (AMDD)
 Code Refactor : เป็นกำร redesign code คือให้แก้ code เพื่อให้มีโครงสร้ำงที่
เข้ำใจได้ง่ำยขึ้น
 Pair Programming : จบัทีมทำ งำนเป็นคู่ 2 คนทำ งำนร่วมกนั ทำ ที่เดียวกนัให้เคร่อืง
เดียว 2 คน,แชร์กนัใช้,คนนึงทำ -คนนึงดู (มีกำรตรวจสอบกนัไปด้วย)
 Test Driven Development(TDD) : เป็นเทคนิคในกำรเขียน Test case เขียน
test case ก่อนและค่อยทำกำร implement code
ตวัอย่ำงกำรเขียน

Methodologies Agile
1) Agile UP (Unified Process)
2) XP (eXtream Programming)
3) FDD (Feature Driven Development)
4) Scrum

Methodologies Agile
o เป็นกระบวนกำรควำมพยำยำมที่จะดึงเอำลกัษณะที่ดีที่สดุของกระบวนกำรด้งัเดิม
ออกมำ แต่ปรบัใช้ในลกัษณะ Implement
o ให้ควำมสำ คญักบักำรส่อืสำรกบัลกูค้ำ และ Use case มำสร้ำงระบบ เพื่อให้
มองเหน็เป้ำหมำยที่ถูกต้อง
o สำมำรถทำ ควำมเข้ำใจ ปรบัเปล่ยีนได้ในอนำคต และนำกลบัมำใช้ใหม่ได้
o กระแสของกระบวนกำรเป็นแบบทำ วนซ้ำ และค่อยเพิ่มขึ้น อนัเป็นลกัษณะของเชิง
วิวฒัน์ที่พบในกำรพฒันำซอฟตแ์วร์สมยัใหม่
o กิจกรรมกรอบงำนประกอบด้วย 5 เฟส และโยงเข้ำกบักิจกรรมท่วัไป
(1) Inception Phase (2) Elaboration Phase
(3) Construction Phase (4) The Transition Phase
(5) The Production Phase

Methodologies Agile
o วิธกีำรเชิงวตัถุและภำษำเชิงวตัถุได้รบัควำมนิยมในหม่วูิศวกรซอฟตแ์วร์ และนำ
แบบจำ ลองและกำรพฒันำระบบเชิงวตัถุที่เรยีกว่ำ UML (Unified Modeling
Languages)
o เป็นกระบวนกำรควำมพยำยำมที่จะดึงเอำลกัษณะที่ดีที่สดุของกระบวนกำรด้งัเดิม
ออกมำ แต่ปรบัใช้ในลกัษณะ Implement
o ให้ควำมสำ คญักบักำรส่อืสำรกบัลกูค้ำ และ Use case มำสร้ำงระบบ เพื่อให้
มองเหน็เป้ำหมำยที่ถูกต้อง
o สำมำรถทำ ควำมเข้ำใจ ปรบัเปล่ยีนได้ในอนำคต และนำกลบัมำใช้ใหม่ได้
o กระแสของกระบวนกำรเป็นแบบทำ วนซ้ำ และค่อยเพิ่มขึ้น อนัเป็นลกัษณะของเชิง
วิวฒัน์ที่พบในกำรพฒันำซอฟตแ์วร์สมยัใหม่
o กิจกรรมกรอบงำนประกอบด้วย 5 เฟส และโยงเข้ำกบักิจกรรมท่วัไป

Methodologies Agile
1
Release
Incept ion
software increment
Elaborat ion
const ruct ion
2
t ransit ion
product ion
3
4
5

Methodologies Agile
o ระยะเรมิ่ต้น (Inception Phase)
- กำรสื่อสำรกบัลูกค้ำ และกิจกรรมกำรวำงแผนงำน ซึ่งกำรพูดคุยจะทำ ให้สำมำรถ
(1) ระบคุวำมต้องกำรทำงธรุกิจ
(2) นำเสนอสถำปัตยกรรมอย่ำงคร่ำว ๆ
(3) วำงแผนโครงงำนในลกัษณะทำ วนซ้ำ หรือ ค่อยเพิ่มขึ้นได้
- กำรนำ เสนอด้วย Use Case ร่นุแรก เสมอืนสถำปัตยกรรมที่บ่งบอก
(1) บคุคล เคร่อืงจกัร หรอืระบบอ่นื ๆ ที่เข้ำมำมปีฏิสมัพนัธ์กบัระบบ
(2) หน้ำที่ ที่ระบบต้องทำ เป็นสงิ่ที่อย่ใูนระบบ สำมำรถถูกเพมิ่เติมในภำยหลงั
(3) ขอบเขตระหว่ำงระบบกบัผู้กระทำ ต่อระบบ
(4) ควำมสมัพนัธ์ของวตัถุ กิจกรรมที่เกิดขึ้นในระบบ
Actor
Use Case
Boundary
Relationship
- กำรวำงแผน ต้องระบทุรพัยำกรที่ต้องใช้ ประเมินควำมเส่ยีงหลกั ๆ กำ หนด
ตำรำงเวลำ และสร้ำงพื้นฐำนสำ หรบัเฟสต่ำง ๆ พฒันำแบบค่อยเพิ่มขึ้น

Methodologies Agile
1) Agile UP (Unified Process) o Inception Phase : Use case Library
Borrow books
<<extends>>
Interlibrary loan
Return books
Do research
Read books,
newspaper
<<include>>
Purchase supplies
Check Library Card
Member
Circulation
Clerk
Supplier

Methodologies Agile
o ระยะขยำยรำยละเอียด (Elaboration Phase)
- ประกอบด้วยกำรส่อืสำรกบัลกูค้ำ และกิจกรรมสร้ำงแบบจำ ลอง กำรขยำย
รำยละเอียด
- ปรบัปรงุ Use case ในระยะเบอื้งต้น ให้ครอบคลมุสถำปัตยกรรมท้งั 5 ของ
ซอฟต์แวร์ ได้แก่
(1) แบบจำลอง Use case
(2) แบบจำลองกำรวิเครำะห์
(3) แบบจำลองกำรออกแบบ
(4) แบบจำ ลองกำรพฒันำ
(5) แบบจำลองกำรนำไปใช้งำน
- ทบทวนกำรสร้ำงแผนงำนอย่ำงละเอยีดในตอนท้ำย เพ่อืให้ม่นัใจในขอบเขตงำน
ควำมเสี่ยง และกำ หนดวนัส่งมอบ ว่ำยงัทำ ได้ตำมกำ หนด

Methodologies Agile
o ระยะก่อสร้ำง (Construction Phase)
- มกีำรพฒันำหรอืจดัหำคอมโพเนนทท์ี่ทำ งำนตำม Use case
- แบบจำ ลองกำรวิเครำะหแ์ละออกแบบจะเสร็จสมบรูณ์ในเฟสนี้
- มกีำรพฒันำลกัษณะและหน้ำที่ของซอฟตแ์วร์ด้วย Source code
- มกีำรทดสอบระดบัหน่วยสำ หรบัแต่ละคอมโพเนนท์
- และอำจมกีำรประกอบคอมโพเนนทแ์ละทดสอบกำรเชื่อมต่อกนั
- กำรทดสอบมกัสร้ำงชุดทดสอบ เพ่อืให้เกิดกำรยอมรบัก่อนถึงเฟสระดบัถดัไป
o ระยะกำรส่งมอบ (The Transitive Phase)
- เป็นระยะท้ำย ๆ ของกิจกรมกำรก่อสร้ำง และระยะต้นของกิจกรรมกำรใช้งำน
- ผู้ใช้งำนจะได้รบัซอฟตแ์วร์เพื่อทดสอบ และรำยงำนจดุบกพร่อง และส่วนที่
จำเป็นต้องเปลี่ยนแปลง
- ทีมงำนจะสร้ำงข้อมลูสนบัสนุนที่จำ เป็น ได้แก่ คู่มอืกำรใช้งำน คู่มอืกำรติดต้งั
ก่อนซอฟต์แวร์จะถูกส่งมอบ หรือวำงตลำด

Methodologies Agile
o ระยะกำรทำ งำน (The Production Phase)
- กิจกรรมกำรใช้งำนท่วัไป มกีำรเฝ้ำดูกำรใช้งำน กำรสนบัสนุนช่วยเหลอื และกำร
รำยงำนจุดบกพร่อง
เฟสก่อสร้ำง เฟสกำรส่งมอบ และเฟสกำรทำงำน อำจเกิดขึ้นได้ในเวลำ
เดียวกัน เนื่องจำกมีกำรเริ่มงำนสำหรับซอฟต์แวร์รุ่นถัดไป เพรำะ
กระบวนกำรนี้ไม่ได้เรียงลำ ดบัข้นั แต่เกิดขึ้นพร้อมกนัเป็นช้นัช้อน ๆ กนั

Methodologies Agile
Incept ion phase
Elaborat ion phase
Const ruct ion phase
Transit ion phase
Vision document
Init ial use- case model
Init ial project glossary
Init ial business case
Init ial risk assessment .
Project plan,
phases and it erat ions.
Business model,
if necessary .
One or more prot ot y pes
I n c e p t i o
n
Use- case model
Supplement ary
r equirement s
including non- funct ional
Analy sis model
Sof t ware archit ect ure
Descript ion.
Execut able archit ect ural
prot ot y pe.
Preliminary design model
Rev ised risk list
Project plan including
it erat ion plan
adapt ed workf lows
milest ones
t echnical work product s
Preliminary user manual
Design model
Sof t ware component s
Int egrat ed sof t ware
increment
Test plan and procedure
Test cases
Support document at ion
user manuals
inst allat ion manuals
descript ion of current
increment
Deliv ered sof t ware increment
Bet a t est report s
General user feedback
These courseware materials are to be used in conjunction with software Engineering: A Pracitioner’s Approach,
Asst.6/e and Prof.are provinced Paijit Suksomboon with permission by R.S.Pressman SoftwareEvolution & Associates, 2 Inc.,/ 44 copyright © 1996,2001,2005
LPRU

Methodologies Agile
o แนวคิดและวิธีกำรเอ็กซ์ทรีมโปรแกรมมิ่งเกิดขึ้นระหว่ำงปลำยทศวรรษที่ 1980
o ใช้แนวทำงเชิงวตัถุในกำรพฒันำระบบ โดยมชีุดของกฏและข้อปฏิบตัิที่ต้องทำ
ระหว่ำงกิจกรรมกรอบงำน 4 อย่ำง (หวัใจหลกั) คือ
(1) กำรวำงแผน (Planning) (2) กำรออกแบบ (Design)
(3) กำรเขียนโค้ด (Coding) (4) กำรทดสอบ (Test)
o ปัจจยัพนื้ฐำน
communication : เน้นเร่อืงกำรพบปะพดูคุย (หลกักำร Agile)
Simplicity : ออกแบบและเขียนโปรแกรมให้ง่ำย ไม่เน้น
performance มำกนกั เน้นเร่อืงแก้ไขให้ถูกต้อง
Feedback : เน้นเรื่องลูกค้ำ feedback เรำเปลี่ยนได้เรื่อยๆ
โดยใช้ refactor
Courage : เรำต้องสำมำรถตดัสินใจเองได้ โปรแกรมเมอร์มคีวำม
กล้ำในกำรตดัสิน

Methodologies Agile
(1) กำรวำงแผน (Planning)
- ทีมพฒันำจะเป็นผู้ทำ หน้ำที่เก็บรวบรวมข้อมูลควำมต้องกำรและวิเครำะห์
ควำมต้องกำรของผู้ใช้เอง แล้วจดัทำ เป็น User Stories
- โดยแต่ละเรื่องเล่ำจะถกูจดัลำ ดบัควำมสำ คญั และถกูนำมำพิจำรณำว่ำแต่ละเรื่อง
ต้องใช้ระยะเวลำและต้นทุนเท่ำใด
- จำกน้นัทีมพฒันำจะให้ผู้ใช้เลือกเร่อืงเล่ำที่ต้องกำรให้พฒันำมำกที่สุด
- จดัเป็นข้อดี เนื่องจำกเป็นกำรเลือกโดยผู้ใช้ภำยใต้ระยะเวลำที่ผู้ใช้ย่อมต้องเป็นผู้
กำ หนดเอง ทำ ให้สำมำรถตดัทอนส่วนที่ไม่จำ เป็นลงไปได้
- จำกน้นัทีมงำนนำมำวิเครำะห์ต้นทุนและผลตอบแทน (Cost-benefit Analysis)
ตำมระยะเวลำที่กำ หนด พร้อมท้งัจดัแบ่งกิจกรรมต่ำง ๆ ออกเป็นรอบตำมจำ นวน
รอบที่เหมำะสม

Methodologies Agile
(2) กำรออกแบบ (Design)
- หลกักำรออกแบบจะยึดหลกั KIS (Keep it Simple) คือ ทำ ให้ง่ำยที่สุด แม้ว่ำ
ระบบจะซำ้ซ้อนมำกก็ตำม โดยกำรจดัทำ ต้นแบบ
- นอกจำกนี้กำรออกแบบยงัได้กำ หนดรำยละเอียดที่เออื้ประโยชน์ในกำรเขียน
โปรแกรมอกีด้วย โดยเพมิ่ฟังก์ช่นัที่คำดว่ำผู้ใช้ต้องกำรไว้ให้
- ไม่สนบัสนุนให้มกีำรออกแบบหน้ำที่อ่นื ๆ นอกเหนือจำกเร่อืงเล่ำ
- ถ้ำมีปัญหำในกำรออกแบบที่ยำกลำ บำกสำ หรบัเรื่องเล่ำใด แนะนำให้สร้ำงต้นแบบ
ที่ทำงำนไดจริง เรียกว่ำ คำตอบสไปค์ (Spike Solution) เพื่อลดควำมเสี่ยงเมื่อมี
กำรพฒันำจริง

Methodologies Agile
(3) กำรเขียนโค้ด (Coding)
- เมื่ออกแบบข้นัต้นแล้ว ไม่ควรเรมิ่เขียนโค้ดในทนัที แต่ควรพฒันำชุดทดสอบ
ระดบัหน่วย ที่จะทำ งำนกบัเรื่องเล่ำแต่ละเรื่องที่สร้ำงขึ้นก่อน จึงเรมิ่เขียนโค้ด
ให้ทำ งำนผ่ำนกำรทดสอบ (ควรทดสอบโดยทนัทีเมื่อเขียนโค้ดเสร็จ)
- แนวคิดที่สำ คญัในกำรทำ งำนแบบเอ็กซ์พี เรียนกว่ำ โปรแกรมเป็นคู่ (Pair
Programming) คือกำรแนะให้คนสองคนทำ งำนร่วมกนั สำ หรบัเรื่องเล่ำเร่อืง
หนึ่ง เครื่องคอมพิวเตอร์เดียวกนั เป็นกลไกที่ช่วยกนัแก้ปัญหำและควบคุม
คุณภำพเฉพำะหน้ำ
- เมื่อคู่โปรแกรมเมอร์ทำ งำนเสร็จ โค้ดจะถูกร่วมเข้ำกบัโค้ดของโปรแกรมอื่น ซึ่ง
บำงคร้งัเกิดขึ้นเป็นประจำ เรียกว่ำ รวมกนัอย่ำงต่อเนื่อง (Continuous
Integration) เป็นกลยุทธ์ที่ช่วยป้องกนักำรทำ งำนเข้ำกนัไม่ได้ของแต่ละส่วน

Methodologies Agile
(4) กำรทดสอบ (Test)
- กำรทดสอบแบบ Unit Test โดยมีกำรสร้ำง Unit Test Case ไว้ก่อนกำรเขียน
โปรแกรมภำยใต้กรอบกำรสร้ำงงำนทดสอบ
- ทำ ให้สำมำรถทดสอบโปรแกรมได้โดยอตัโนมตัิ และทำ ให้ง่ำยต่อกำรทดสอบซำ้
เมื่อต้องแก้ไขโปรแกรม
- จำกน้นั จะนำไปให้ลกูค้ำทดสอบ เรียกว่ำ Customer Test ซึ่งก็คือ กำรทดสอบ
กำรยอมรบั (Acceptance Test) น่นัเอง

Methodologies Agile
สรปุกิจกรรม
1) วำงแผน
2) พยำยำมซอยงำนให้ถี่ๆ
3) มีตวักลำงค่นัระหว่ำง user และตวัเรำ
4) ออกแบบให้ง่ำย
5) ทดสอบเสมอ
6) แก้ code บ่อยๆ (refactoring)
7) ทำงำนเป็นคู่ (pair programming)
8) Team code ownership
9) ทำ กำรรวบรวมงำนอย่ำงต่อเนื่อง (เพรำะงำนที่ทำ เรำแบ่งเป็นชนิ้เล็กๆ)
10) ทำ งำนไปเรื่อยๆ ไม่หกัโหม ห้ำมว่ำง
11) มองทีมเป็นหนึ่ง
12) ใช้มำตรฐำนกำร code แบบเดียวกนั กรณีใน OO มีมำตรฐำนเช่น (1) 1 class
มี 1 file (2) ต้งัชื่อ ns เป็นมำตรฐำ

Methodologies Agile
o เรมิ่จำกกำรค้นค้นของ Peter Cord และคณะ ในปี 1999 จำกหนงัสือ “Java
model in color with UML” เพื่อใช้เป็นกระบวนกำรเชิงปฏิบตัิของวิศวกรรม
ซอฟต์แวร์เชิงวตัถุ
o จำกน้นัจึงมีขยำยและเพมิ่งำนท่สีำมำรถประยุกตใ์ช้กบัโครงกำรขนำดกลำงและ
ขนำดใหญ่ขึ้น
o ปกติเวลำเรมิ่ต้นโครงกำรเรำต้องกำ หนด stakeholder ว่ำมใีครบ้ำง จำกน้นักเ็ก็บ
business goals (BG) กบั stakeholder เหล่ำน้นั ซึ่ง BG ปัญหำและเป้ำหมำย
ของเขำ ซึ่งทำงทีมพฒันำฯ ต้องทำ ควำมเข้ำใจ
o และที่สำ คญัควรมอีกีทีมที่ทำ หน้ำที่ทำ ควำมเข้ำใจและตีควำม BG เหล่ำน้นั เพรำะ
หลำยคร้งัมกัพบว่ำทีมพฒันำฯ ขำดทกัษะด้ำนธรุกิจหรอืมีไม่พอทำ ให้ตีควำมผิด
และเข้ำใจคลำดเคล่อืน สมยันี้หลำยองค์กรจึงมคีนที่รบับทบำท เช่น solution
architect, business IT strategist, ฝ่ำยกำรตลำด เป็นต้น เพื่อทำควำมเข้ำใจ
กบั BG เหล่ำน้นั

Methodologies Agile
o แล้วมำวิเครำะห์โอกำส (และอีกหลำยอย่ำง) เพื่อหำว่ำควรต้องมีระบบฯ หรือ
แอพพลิเคช่นัใดบ้ำง และควรมีควำมสำมำรถ (Feature) ใดบ้ำง
o เมื่อระบุ feature เรียบร้อยแล้วก็เสนอลูกค้ำหรือผู้บริหำรครบั เมื่อตกลงยืนยนักนั
ตำมนี้ feature ก็ถือเป็น commitment ระหว่ำงทีมพฒันำฯ และผู้บริหำร (หรือ
ลูกค้ำ) กำรบริหำรโครงกำรก็ต้อง base on feature
o จำกนั้นก็เริ่มเก็บ requirements กัน ไม่ว่ำจะเป็นด้ำน functional
requirements, non-functional requirements ซึ่งแต่ละควำมต้องกำรต้อง
ระบุด้วยว่ำสัมพันธ์กับ feature ใด (requirements traceability) โดย
software artifact ทุกประเภทต้องระบุว่ำสัมพนัธ์กบัควำมต้องกำรใดและ
feature ใด ไม่ว่ำจะโมเดล diagram เอกสำร ซอร์สโค้ด test case ฯ ต้องระบุให้
หมด เพรำะทุกอย่ำงต้องสอดคล้องกบั feature ซึ่งในขณะเดียวกนั feature เองก็
ต้องระบุด้วยว่ำสมัพนัธ์กบั BG ใดบ้ำง เพื่อประโยชน์ต่อกำรตรวจสอบย้อนกลบั
หรือไปข้ำงหน้ำ (Traceability)

Methodologies Agile
o คุณลกัษณะ “หน้ำที่ที่ลกูค้ำเหน็ว่ำมคีุณค่ำ ที่สำมำรถพฒันำได้ภำยในเวลำ 2 – 4
สปัดำห”์ ดงันี้
(1) เนื่องจำกคุณลกัษณะเป็นส่วนเล็ก ๆ ของซอฟต์แวร์ที่ทำ งำนได้ จึงสำมำรถ
อธิบำยและเข้ำใจควำมสมัพนัธ์ระหว่ำงกนัได้ง่ำยกว่ำ และสำมำรถทบทวนได้
ดีกว่ำ หำกคลุมเครือข้อผิดลำด หรือหลงลืม
(2) คุณลกัษณะอำจถูกจดัระเบียบ เป็นกลุ่มลำ ดบัช้นัที่มีควำมสมัพนัธ์ทำงธุรกิจ
(3) คุณลกัษณะซอฟต์แวร์ที่ต้องส่งมอบได้ในกำรพฒันำแบบ FDD ทีมงำนจะมุ่ง
พฒันำซอฟต์แวร์ให้มีคุณลกัษณะใหม่ ๆ ที่ทำ งำนได้ทุก ๆ 2 สปัดำห์
(4) คุณลกัษณะมีขนำดเล็ก ตวัแบบและโค้ดจึงง่ำยต่อกำรตรวจทำนอย่ำงละเอียด
(5) กำรวำงแผน จดัตำรำงงำน ติดตำมกำรขบัเคลื่อนด้วยคุณลกัษณะตำมลำ ดบั
ซึ่งดีกว่ำกำรใช้ชุดง่ำยย่อยที่เลือกมำแบบสุ่ม

Methodologies Agile
3) FDD กระบวนกำรร่วมมอื 5 ระดบัของ FDD
o หลกัไมล์ในช่วงกำรออกแบบ 6 หลกั :
(1) กำรออกแบบคร่ำว ๆ (2) กำรออกแบบ (3) กำรตรวจทำนกำรออกแบบ
(4) กำรโค้ด (5) กำรตรวจทำนกำรโค้ด (6) กำรส่งเสริมกำรสร้ำง

3) FDD : Milestones
Methodologies Agile
o หลกัไมล์ในช่วงกำรออกแบบ 6 หลกั :
(1) กำรออกแบบคร่ำว ๆ (2) กำรออกแบบ (3) กำรตรวจทำนกำรออกแบบ
(4) กำรโค้ด (5) กำรตรวจทำนกำรโค้ด (6) กำรส่งเสริมกำรสร้ำง

Methodologies Agile
o บทบำทและหน้ำที่ที่จำ เป็นต้องมเีพ่อืสนบัสนุนให้เกิดควำมกระบวนกำรที่ถูกต้อง
1. Domain Manager
2. Release Manager
3. Language Guru
4. Build Engineer
5. Toolsmith
6. System Administrator
7. Tester
8. Deployer
9. Technical Writer

4) Scrum
Methodologies Agile
o สครมัมำจำกกิจกรรมในกำรแข่งขนัรกับี้ เป็นกระบวนกำรอำไจลที่พฒันำโดย Jeff
Sutherland และทีมงำน เมื่อต้นทศวรรษ 1990
o หลกักำรของสครมัมดีงัต่อไปนี้
(1) จดัต้งัทีมทำ งำนขนำดเล็กที่ “เกิดกำรสื่อสำร กำรแบ่งปันเทคนิค และข่ำวสำรที่
ไม่เป็นทำงกำรให้มำกที่สุด ขณะที่ลดค่ำใช้จ่ำยส่วนเกินให้น้อยที่สุด”
(2) กระบวนกำรต้องสำมำรถปรบัเข้ำกบักำรเปล่ยีนแปลงทำงธรุกิจและเทคนิคได้
เพื่อผลิตผลงำนให้ดีที่สุด
(3) กระบวนกำรต้องผลิตร่นุซอฟต์แวร์ออกมำบ่อย ๆ เพื่อตรวจสอบ ปรบัแต่ง
ทดสอบ บนัทึกและต่อยอดได้
(4) งำนที่พฒันำและนกัพฒันำจะแบ่งออกเป็นแพ็คเก็ตหรือพำร์ติดช่นัที่สดุและ
ขึ้นแก่กนัน้อยที่สุด
(5) มีกำรทดสอบและบนัทึกเอกสำรอย่ำงสม่ำ เสมอขณะสร้ำงผลิตภณัฑ์
(6) กระบวนกำรสครมัจะต้อง “สำมำรถแจ้งว่ำ พฒันำผลิตภณัฑ์เสร็จแล้ว”
เมื่อใดก็ตำมที่ต้องกำร (มกีำรแข่งขนัสงู/บ.ต้องกำรเงิน/ลค.ต้องกำรใช้งำน)

4) Scrum
Methodologies Agile
o หลกักำรสครมัใช้นำ ทำงกิจกรรมพฒันำ ภำยใต้กระบวนกำรที่รวมเอำกิจกรรมกรอบ
งำนต่อไปนี้ คือ ควำมต้องกำร กำรวิเครำะห์ กำรออกแบบ กำรวิวฒัน์ และกำรส่ง
มอบ ที่พิสจูน์แล้วว่ำได้รบัผลดี
o สำ หรบัโครงกำรที่มีเวลำจำ กดั มีกำรเปลี่ยนแปลงควำมต้องกำร และมีควำมสำ คญั
อย่ำงยงิ่ยวดต่อธรุกิจ แบบรปูกระบวนกำรแต่ละแบบนิยำมชุดกิจกรรมพฒันำระบบ
ต่อไปนี้
- แบ็คล๊อก (Backlog) รำยกำรควำมต้องกำรหรือลกัษณะที่ให้คุณค่ำทำงธุรกิจแก่
ลูกค้ำที่เรียงลำ ดบัควำมสำ คญัแล้ว รำยกำรอำจเพมิ่เข้ำมำใหม่ได้ โดยผู้จดักำรต้อง
ประเมินและปรบัปรุงลำ ดบัควำมสำ คญัตำมควำมเหมำะสม
- สปรนิ้ (Sprints) ประกอบด้วยหน่วยของงำน ต้องทำ ให้เสร็จตำมควำมต้องกำรที่
นิยำมโดยแบ็คล๊อก โดยหน่วยของงำนหนึ่ง ๆ ต้องทำให้เสร็จได้จริงตำมกรอบ
เวลำที่กำ หนดไว้แล้วล่วงหน้ำ (ปกติ 30 วนั) ระหว่ำงสปรนิ้ รำยกำรแบ็คล็อกใดที่
กำ หนดสปรนิ้อยู่จะถูกหยุดกำรเปล่ยีนแปลงไว้ก่อน

4) Scrum
Methodologies Agile
- กำรพบปะของสครมั (Scrum meeting) กำรประชุมส้นั ๆ ประมำณ 15 นำที
ของทีมสครมัจะมีทุก ๆ วนั เพื่อถำมและตอบคำ ถำมสำมข้อ คือ
(1) คุณได้ทำ อะไรไปแล้วหลงัจำกกำรประชุมคร้งัที่แล้ว
(2) มีอุปสรรคอะไรหรือไม่ที่พบ
(3) คุณวำงแผนจะทำอะไรให้เสร็จก่อนกำรประชุมครำวหน้ำ
หวัหน้ำทีมสครมั (Scrum Master) จะนำกำรประชุมและประเมินกำรตอบสนอง
ของแต่ละบุคคล กำรประชุมสครมัช่วยให้ทีมค้นพบปัญหำเร็วที่สุดเท่ำที่จะทำ ได้
นอกจำกนี้ยงัเป็นกำรสงัสรรค์เชิงควำมรู้ และช่วยก่อให้เกิดโครงสร้ำงทีมจดั
ระเบียบตนเองได้ด้วย
- สำธิต (Demos) ส่งมอบรุ่นซอฟต์แวร์แก่ลูกค้ำเพื่อสำธิตและประเมินหน้ำที่กำร
ทำ งำนที่ได้พฒันำแล้ว กำรสำธิตไม่จำ เป็นต้องมีหน้ำที่ครบถ้วนตำมแผนที่วำงไว้
แต่ต้องมีหน้ำที่ที่ส่งมอบได้ภำยในกรอบเวลำที่กำหนด

4) Scrum
Methodologies Agile
สครมัทีมจะถูกปลกูจิตสำ นึกว่ำ “We’re all in this together”
A typical Scrum team is 6-10 people but Jeff Sutherland has scaled
Scrum up to over 500 people

บทสรุป
Methodologies Agile
Agile อำจเป็นเพียงวิธีกำรแบบหนึ่ง เป็นวิธีที่ฉีกแนวจำก
ควำมคิดในกำรกระทำ แบบเดิม ซึ่งมีข้อดีอยู่มำก แต่ยงัมีหลำยด้ำนที่เป็น
ข้อด้อย
Agile ถือเป็นเรื่องใหม่ ขณะนี้จะมองว่ำเป็นไปตำมสมยันิยม
(fashion) หรืออนำคตก็ได้ท้งัสองอย่ำง แนวคิดอย่ำง Agile กำ ลงั
เริ่มต้นเท่ำนั้น ยังรอคอยกำรลองผิดลองถูก รูปแบบแอพพลิเคชั่นใน
ปัจจุบันก็แตกต่ำงกันมำกขึ้นทุกวัน เครื่องมือกำรพัฒนำซอฟต์แวร์ก็
พฒันำไปมำก เพียงรูปแบบแอพพลิเคช่นัในอนำคตยงัคำดกำรณ์ไม่ได้
วิธีกำรพฒันำก็คงจะเป็นเช่นเดียวกนั และเป็นกำรยำกที่จะบอกว่ำ Agile
ดีกว่ำแบบอื่น ๆ เพรำะขึ้นอยู่กบัสถำนกำรณ์ที่จะนำไปประยุกต์ใช้และ
วฒันธรรมขององค์กรเป็นสำ คญั

Sw evo 2_model

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Sw evo 2_model

Similaire à Sw evo 2_model (20)

Sw evo 2_model