กระบวนการซอฟต์แวร์ (Software Process)

Download Report

Transcript กระบวนการซอฟต์แวร์ (Software Process)

290355 Software Engineering
บทที2่
กระบวนการทางวิศวกรรมซอฟต์ แวร์
อ.ธารารัตน์ พวงสุ วรรณ
คณะวิทยาศาสตร์ และศิลปศาสตร์
มหาวิทยาลัยบูรพา วิทยาเขตสารสนเทศจันทบุรี
เนือ้ หา






กระบวนการซอฟต์แวร์ (Software Process)
กิจกรรมพื้นฐานของกระบวนการทางวิศวกรรมซอฟแวร์
วงจรการพัฒนาซอฟต์แวร์ (Software Development Life Cycle)
โมเดลการพัฒนาซอฟต์แวร์
เทคนิคและเครื่ องมือในการพัฒนาซอฟต์แวร์
แบบจาลองวุฒิภาวะความสามารถ (Capability Maturity Model: CMM)
กระบวนการ (Process)
กระบวนการ (Process) คือ กลุ่มของขั้นตอนการ
ทางาน ที่ประกอบด้วยชุดกิจกรรม ข้อจากัด และทรัพยากร
ที่จะได้ผลิตเป็ นผลลัพธ์บางชนิดตามต้องการ
กระบวนการ (Process) จะมีลาดับขั้นตอนในการผลิตจะ
ดาเนินการตามลาดับเหมือนเดิมทุกครั้ง
3
กระบวนการ (Process)
กระบวนการโดยทั่วไปจะมีลกั ษณะ ดังนี้
1. กระบวนการจะต้องระบุกิจกรรมทั้งหมดอย่างชัดเจน
2. กระบวนการจะใช้ทรัพยากรภายใต้ขอ้ จากัดต่างๆ เพื่อ
ผลิตเป็ นผลิตภัณฑ์ที่แล้วเสร็ จ
3. กระบวนการหนึ่ง อาจประกอบขึ้นจากกระบวนการย่อย
อื่นๆ ที่มีความสัมพันธ์กนั
4
กระบวนการ (Process)
4. ทุกกิจกรรมของกระบวนการจะมีเงื่อนไขในการเริ่ มต้น
และสิ้ นสุ ดกิจกรรม
5. ทุกขั้นตอนและทุกกิจกรรมของกระบวนการจะต้องมีเป้ าหมาย
อย่างชัดเจน และต้องมีหลักการหรื อแนวทางในการปฏิบตั ิ
เพื่อให้บรรลุเป้ าหมายนั้น
6. ข้อจากัดหรื อเงื่อนไขสามารถนามาใช้ควบคุมการดาเนินกิจกรรม
การใช้ทรัพยากร หรื อแม้กระทัง่ ตัวผลิตภัณฑ์เองได้
5
วิศวกรรมซอฟต์แวร์ คือ ระเบียบแบบแผนที่นามา
ประยุกต์ใช้กบั การพัฒนาซอฟต์แวร์เพื่อให้เกิดประสิ ทธิ ภาพต่อ
การพัฒนา มีกระบวนการพัฒนาซอฟต์แวร์ที่ชดั เจนและสามารถ
ตรวจสอบได้ นอกจากนี้ยงั มีการนาเครื่ องมือสนับสนุนการ
พัฒนาระบบมาใช้เพื่อให้เกิดมาตรฐานเดียวกันและทาให้
ซอฟต์แวร์มีคุณภาพ
วิศวกรรมซอฟต์แวร์ได้เข้ามามีบทบาทสาคัญต่อ
กระบวนการพัฒนาซอฟต์แวร์ เพื่อให้ซอฟต์แวร์มีมาตรฐาน
และเป็ นวิทยาศาสตร์มากขึ้น
กระบวนการซอฟต์ แวร์ (Software Process)
•
เพือ่ ให้ บรรลุวตั ถุประสงค์ ในการสร้ างซอฟต์ แวร์ จึงต้ องมีการกาหนด
กระบวนการสร้ างซอฟต์ แวร์
•
สิ่ งที่ได้ จากกระบวนการสร้ างซอฟต์ แวร์ คือ ผลิตภัณฑ์ ซอฟต์ แวร์
(Software Product)
•
วิศวกรรมซอฟต์ แวร์ จะเรียกกระบวนการสร้ างซอฟต์ แวร์ ว่า
“Software Process”
7
Software Process
•
กระบวนการซอฟต์ แวร์ คือ กรอบการดาเนินกิจกรรมในการสร้าง
ซอฟต์แวร์ที่มีคุณภาพ [Pressman, 2005]
•
กระบวนการซอฟต์ แวร์ คือ กลุ่มของกิจกรรมและผลลัพธ์ของแต่ละ
กิจกรรมเพื่อการผลิตเป็ นผลิตภัณฑ์ที่เรี ยกว่า “ซอฟต์แวร์ ”
[Sommerville, 2007]
8
กิจกรรมพืน้ ฐานของ
กระบวนการทางวิศวกรรมซอฟต์ แวร์
1. ข้อกาหนดซอฟต์แวร์ (Software Specification)
2. การพัฒนาซอฟต์แวร์ (Software Development)
3. การตรวจสอบความถูกต้อง (Software Validation)
4. วิวฒั นาการของซอฟต์แวร์ (Software Evolution)
1. software specification
นิยามหน้าที่ต่างๆที่ตอ้ งมีในซอฟต์แวร์ และระบุขอ้ จากัดต่างๆ ที่เกี่ยวข้องกับกระบวน
พัฒนาซอฟต์แวร์
2. Software Development
ทาการสร้าง / พัฒนาซอฟต์แวร์ให้ตรงกับข้อกาหนด (specification)
3. software validation
ทาการตรวจสอบความถูกต้องของซอฟต์แวร์ เพื่อให้เกิดความมัน่ ใจ ว่าซอฟต์แวร์ที่ผลิต
ขึ้นได้ตรงกับความต้องการของลูกค้า
4. software evolution
ในทางปฏิบตั ิ เมื่อซอฟต์แวร์ใช้งานได้ระยะหนึ่งแล้ว ผูใ้ ช้หรื อลูกค้าอาจมีความต้องการ
เพิม่ เติมหรื อเปลี่ยนแปลงความต้องการบางอย่าง ดังนั้นขั้นตอนการพัฒนาซอฟต์แวร์ ต้อง
มีการเตรี ยมการบางอย่างเพื่อจัดการกับเหตุการณ์ที่คาดหมายว่าจะเกิดขึ้นในอนาคต
10
Software Process




กระบวนการซอฟต์แวร์ประกอบด้วย คน วิธีการ และเครื่ องมือ
ในกระบวนการผลิตซอฟต์แวร์ อาจแตกต่างกันที่เครื่ องมือ เทคนิค และ
เทคโนโลยีที่เลือกใช้
ในกระบวนการผลิตซอฟต์แวร์ มีการดาเนินการตามลาดับขั้นตอนเหมือนกัน
กิจกรรมต่าง ๆ ในกระบวนการผลิตซอฟต์แวร์สามารถปรับเปลี่ยนให้เข้ากับ
ลักษณะงานได้
11
Software Process

กระบวนการซอฟต์ แวร์ (Software Process) = กระบวนการพัฒนา
ซอฟต์ แวร์ (Software Development Process)

กระบวนการทาหน้ าที่เป็ นกรอบในการสร้ างผลิตภัณฑ์ ใด ๆ หรือเรียก
กระบวนการ ได้ อกี อย่ างว่ า “วงจรชีวติ หรือวัฏจักรชีวติ (Life Cycle)”
ของผลิตภัณฑ์

กระบวนการซอฟต์ แวร์ หรือ กระบวนการพัฒนาซอฟต์ แวร์ เรียกอีกอย่ าง
หนึ่งว่ า “วัฏจักรชีวติ ของซอฟต์ แวร์ (Software Life Cycle)” หรือ วงจร
การพัฒนาซอฟต์ แวร์ (Software Development Life Cycle : SDLC)
12
Software Development Life Cycle : SDLC
คุณสมบัติเด่น
 มีการแบ่งกระบวนการทางานออกเป็ นขั้นตอน
 มีการทางานที่เป็ นลาดับขั้นตอนที่ต่อเนื่ อง
Software Development Life Cycle : SDLC
ระยะที่ 1: การวางแผนโครงการ (Project Planning Phase)
ระยะที่ 2: การวิเคราะห์ (Analysis Phase)
ระยะที่ 3: การออกแบบ (Design Phase)
ระยะที่ 4: การนาไปใช้ (Implementation Phase)
ระยะที่ 5: การบารุ งรักษา (Maintenance Phase)
วงจรการพัฒนาระบบ
(System Development Life Cycle: SDLC)
ระยะที่ 1: การวางแผนโครงการ
ระยะที่ 2: การวิเคราะห์
ระยะที่ 3: การออกแบบ
ระยะที่ 4: การนาไปใช้
ระยะที่ 5: การบารุ งรักษา
2
Analysis Phase
1
Project Planning
Phase
5
Maintenance Phase
3
Design Phase
SDLC
4
Implementation Phase
ระยะที่ 1 Project Planning
ประกอบด้วยกิจกรรม ดังนี้
 กาหนดปั ญหา (Problem Definition)
 ศึกษาความเป็ นไปได้ของโครงการ (Feasibility Study)
 จัดทาตารางกาหนดเวลาโครงการ (Project Scheduling)
 จัดตั้งทีมงานโครงการ (Staff the project)
 ดาเนิ นการโครงการ (Launch the project)
กาหนดปัญหา (Problem Definition)
ค้ นหาปัญหา โอกาสและเป้ าหมาย
(Identifying Problems, Opportunity and Objective)
ระบบสารสนเทศจะเกิดขึ้นได้กต็ ่อเมื่อผูบ้ ริ หารหรื อผูใ้ ช้ตระหนักว่า
ต้องการระบบสารสนเทศ หรื อต้องแก้ไขระบบเดิม โดยมีข้นั ตอนดังนี้
1.1 นักวิเคราะห์และออกแบบระบบ ต้องศึกษาระบบโดยละเอียด เพือ่ ให้
เข้าใจถึงปั ญหาที่เกิดขึ้นในองค์กร ตัวอย่างปั ญหา
1.2 พยายามหาโอกาสในการปรับปรุ งวิธีการทางานโดยการใช้ระบบ
คอมพิวเตอร์
1.3 นักวิเคราะห์และออกแบบระบบ ต้องมองเป้ าหมายให้ชดั เจน
ตัวอย่ างการเข้ าใจปัญหา




บริ ษทั A ติดต่อซื้อขายจากผูข้ ายหลายบริ ษทั ด้วยกัน
บริ ษทั A มีระบบ MIS ที่เก็บข้อมูลเกี่ยวกับหนี้สินที่บริ ษทั ติดค้างผูข้ ายอยู่
แต่ระบบสามารถเก็บข้อมูลผูข้ ายได้เพียง 1000 รายเท่านั้น
ปัจจุบนั ระบบมีขอ้ มูลผูข้ ายเก็บอยู่ 900 รายและในอนาคตอันใกล้จะเกิน
1000 รายแน่นอน
ดังนั้น ก่อนจะเกิดปัญหาขึ้น ต้องมีการพัฒนาระบบให้รองรับขนาดจานวน
ผูข้ ายได้มากขึ้น
ศึกษาความเป็ นไปได้ (Feasibility Study)


เมื่อกาหนดว่าปัญหาคืออะไร และตัดสิ นใจว่าจะพัฒนาสร้างระบบสารสนเทศ
ใหม่หรื อการแก้ไขระบบสารสนเทศเดิมมีความเป็ นไปได้หรื อไม่ โดยเสี ย
ค่าใช้จ่ายและเวลาน้อยที่สุด
นักวิเคราะห์และออกแบบระบบ ต้องกาหนดให้ได้วา่ การแก้ปัญหานั้น
2.2.1 มีความเป็ นไปได้ทางเทคนิคหรื อไม่
2.2.2 มีความเป็ นไปได้ทางบุคลากรหรื อไม่
2.2.3 มีความเป็ นไปได้ทางเศรษฐศาสตร์หรื อไม่ (ต้นทุนค่าใช้จ่าย)
การศึกษาความเป็ นไปได้ น้ ันสามารถสรุ ปได้ ดงั ต่ อไปนี้
• หน้าที่ : ศึกษาว่าเป็ นไปได้หรื อไม่ที่จะเปลี่ยนแปลงระบบ
• ผลลัพธ์ : รายงานความเป็ นไปได้
• เครื่ องมือ : เก็บรวบรวมข้อมูลของระบบและคาดคะเนความต้องการของระบบ
• บุคลากรและหน้าที่รับผิดชอบ
• นักวิเคราะห์และออกแบบระบบ
- ต้องเก็บรวบรวมข้อมูลทั้งหมดที่จาเป็ น
- ต้องคาดคะเนความต้องการของระบบและแนวทางแก้ไขปัญหา
- กาหนดความต้องการที่แน่ชดั เพือ่ ใช้ในการวิเคราะห์ระบบ โดยที่ผบู ้ ริ หารจะ
ตัดสิ นใจว่าจะดาเนินโครงการต่อไปหรื อไม่หรื อยกเลิกโครงการ
ระยะที่ 2 Analysis Phase
จะมีคาตอบกับคาถามว่า ใคร(Who) เป็ นผูใ้ ช้งานระบบ และมีอะไรบ้าง
(What) ที่ระบบต้องทา
 ดาเนิ นการวิเคราะห์ระบบปั จจุบน
ั เพื่อพัฒนาแนวความคิดสาหรับระบบ
ใหม่
 วัตถุประสงค์หลัก คือ ศึกษาทาความเข้าใจความต้องการต่าง ๆ ทีไ่ ด้
รวบรวมมา
 ดังนั้น การรวบรวมความต้องการ (Requirement Gathering) จึงเป็ นงาน
ส่ วนพื้นฐานของการวิเคราะห์ ซึ่งนักวิเคราะห์ระบบจะประเมินว่าควรมี
อะไรบ้างที่ระบบใหม่ตอ้ งดาเนินการ
 ดังนั้น การกาหนดรายละเอียดเกี่ยวกับความต้องการของผูใ้ ช้ (User
Requirement) จะมีความสาคัญมาก

ระยะที่ 2 Analysis Phase

นักวิเคราะห์ระบบรวบรวมความต้องการได้จาก
 การสังเกต
 การสัมภาษณ์
 การทาแบบสอบถาม
 การอ่านเอกสารเกี่ยวกับการปฏิบต
ั ิงานของระบบ
 ระเบียบกฏเกณฑ์

จากนั้นจึงสรุ ปออกมาเป็ นข้อกาหนด (Requirement Specification) ที่
ชัดเจน อ่านแล้วตีความหมายได้ตรงกัน
ระยะที่ 2 Analysis Phase
หลังจากนั้น นักวิเคราะห์ระบบต้องนาข้อกาหนดไปพัฒนาเป็ นความ
ต้องการของระบบใหม่ เทคนิคที่ใช้คือ การพัฒนาแบบจาลอง
กระบวนการ (Process Model) เพื่ออธิบายกระบวนการที่ตอ้ งทาในระบบ
และจากนั้น ก็ดาเนินการพัฒนาแบบจาลองข้อมูล (Data Model) เพื่อ
อธิบายสารสนเทศที่ตอ้ งจัดเก็บเอาไว้สนับสนุนกระบวนการต่าง ๆ
 เทคนิ คที่ใช้ในการวิเคราะห์ระบบ อาจปรับเปลี่ยนไปตามเทคนิ คที่
เลือกใช้ในการวิเคราะห์ระบบ

ระยะที่ 3 Design Phase


พิจารณาว่า ระบบจะดาเนินการไปได้อย่างไร (How) จะพัฒนาระบบใหม่ดว้ ย
แนวทางใด
เกี่ยวข้องกับการออกแบบสถาปั ตยกรรมระบบ เกี่ยวกับอุปกรณ์ฮาร์ดแวร์
ซอฟต์แวร์ เครื อข่าย การออกแบบรายงาน การออกแบบหน้าจอ ออกแบบผัง
งานระบบ รายละเอียดโปรแกรม ฐานข้อมูล แฟ้ มข้อมูลที่เกี่ยวข้อง
ระยะที่ 3 Design Phase

ประกอบด้วยกิจกรรม ดังนี้
 พิจารณาแนวทางในการพัฒนาระบบ
 Architectural Design
 Database Design
 Output Design
 Input Design
 User Interface Design
 Prototype
 ออกแบบโปรแกรม (Structure chart)
ระยะที่ 5 Implementation Phase
 เขียนโปรแกรม
 ตรวจสอบความถูกต้อง
 Verification ตรวจสอบว่า ระบบทางานตามที่กาหนดไว้หรื อไม่

Validation ตรวจสอบว่า ระบบสามารถทางานตามความต้องการ
ของผูใ้ ช้หรื อไม่
 เตรี ยมสถานที่และการติดตั้งเครื่ องคอมพิวเตอร์
 จัดทาคู่มือการใช้โปรแกรมและการฝึ กอบรมผูใ้ ช้ที่เกี่ยวข้องใน
ระบบ
กรรมวิธีการพัฒนาระบบ (System Development Methodology)
นั ก วิ เ คราะห์ ระบบ สามารถน าเครื่ องมื อ ต่ า ง ๆ มาประยุก ต์ ใ ช้ กั บ การ
วิเคราะห์ และออกแบบ ซึ่ งเรี ยกว่ า “Methodology” โดย Methodology เป็ น
แนวทางที่ มีการนาโมเดล (Model), เครื่ องมือ (Tools) และเทคนิค (Techniques)
ต่ าง ๆ มาใช้ กับการพัฒนาซอฟต์ แวร์ ซึ่ งจั ดเป็ นแนวทางในการแก้ ปัญ หาด้ วย
วิธีการพัฒนาซอฟต์ แวร์
กรรมวิธีการพัฒนาระบบ (System Development Methodology)
โมเดล (Models)
ประกอบด้ วยการนาเสนอสิ่ งที่ เกี่ยวกับการอิ นพุต เอาต์ พุต โปรเซส ข้ อมูล
ออบเจ็กต์ การโต้ ตอบระหว่ างออบเจ็กต์ สถานที่ ตั้ง เครื อข่ าย และอุ ปกรณ์ อื่นๆ
ซึ่ งโดยส่ วนใหญ่ แล้ วโมเดล หรื อแบบจาลองนีจ้ ะนาเสนอในรู ปแบบของภาพ ซึ่ ง
ประกอบด้ วยไดอะแกรม (Diagram) หรื อแผนภูมิ (Chart)
เครื่ องมือ (Tools)
ประกอบด้ วยซอฟต์ แวร์ หรื อโปรแกรมที่ ใช้ สนับสนุนการใช้ งานเครื่ องมือ
เหล่ านี ้สามารถนามาใช้ งานเพื่ อสร้ างแบบจาลองหรื อโมเดลต่ าง ๆ และรวมถึ ง
ส่ วนประกอบอื่น ๆ
กรรมวิธีการพัฒนาระบบ (System Development Methodology)
เทคนิค (Techniques)
คือกลุ่มแนวทางที่ ช่วยในการชี ้นา (Guidelines) เพื่อให้ นักวิเคราะห์ ระบบ
สามารถนาเทคนิ คไปดาเนิ นกิ จกรรมการพัฒนาระบบเพื่ อให้ เกิ ดความสมบูรณ์
ยิ่งขึน้
• เทคนิคการบริ หารโครงการ
• เทคนิคการสั มภาษณ์
• เทคนิคการทดสอบซอฟต์ แวร์
• เทคนิคการวิเคราะห์ และออกแบบระบบเชิ งวัตถุ
วิธีการพัฒนาระบบ มี 2 วิธี
1. วิธีการพัฒนาระบบแบบดั้งเดิม (The Traditional Approach)
เทคนิควิธีการพัฒนาระบบดั้งเดิมนั้นมีเทคนิ คที่ หลากหลาย ซึ่ งตั้ งอยู่บนพืน้ ฐาน
ของการพัฒนาระบบสารสนเทศด้ วยวิธีโครงสร้ าง และการโปรแกรมแบบโมดูล
โดยมักเรี ยกวิธีนีว้ ่ า การพัฒนาระบบเชิ งโครงสร้ าง
การโปรแกรมเชิ ง โครงสร้ างนอกจากจะช่ ว ยให้ การเขี ย นโปรแกรมมี
คุณภาพแล้ ว ยังมีส่วนช่ วยให้ โปรแกรมเมอร์ สามารถอ่ านโปรแกรมเพื่อ ทาการ
ตรวจสอบและท าการแก้ ไ ขปรั บ ปรุ ง โปรแกรมได้ ง่ า ยขึ ้น โดยแนวทางการ
โปรแกรมเชิ งโครงสร้ าง ประกอบด้ วย ชุดคาสั่ งที่ เรี ยงลาดับ (Sequence) ชุดคาสั่ ง
ที่ มีการตัดสิ นใจ (Decision) และชุดคาสั่ งที่ มีการทางานเป็ นลูปหรื อการทาซ้า
(Repetition)
วิธีการพัฒนาระบบ มี 2 วิธี
1. วิธีการพัฒนาระบบแบบดั้งเดิม (The Traditional Approach)
วิธีการพัฒนาระบบ มี 2 วิธี
1. วิธีการพัฒนาระบบแบบดั้งเดิม (The Traditional Approach)
วิธีการพัฒนาระบบ มี 2 วิธี
1. วิธีการพัฒนาระบบแบบดั้งเดิม
(The Traditional Approach)
การวิ เคราะห์ เชิ งโครงสร้ างสมัยใหม่ เป็ น
เทคนิ ค ที่ ช่ วยให้ นั ก พั ฒ นาก าหนดได้ ว่ า
ระบบจะต้ อ งด าเนิ น การท าอะไรบ้ า ง มี
ข้ อมูลใดบ้ างที่ ระบบต้ องจั ดเก็บ มี อินพุต
และเอาต์ พุตใด และต้ องดาเนินการอย่ างไร
ให้ ระบบโดยรวมสาเร็ จลงด้ วยดี
วิธีการพัฒนาระบบ มี 2 วิธี
วิธีการพัฒนาระบบ มี 2 วิธี
วิธีการพัฒนาระบบ มี 2 วิธี
2. วิธีการพัฒนาระบบเชิ ง
วัตถุ (The ObjectOriented Approach)
จัดเป็ นวิธีใหม่ ของการ
พัฒนาระบบ
วิธีการพัฒนาระบบ มี 2 วิธี
2. วิธีการพัฒนาระบบเชิ งวัตถุ (The Object-Oriented Approach) จัดเป็ นวิธีใหม่ ของ
การพัฒนาระบบ
จะประกอบไปด้ วย 3 แนวทางด้ วยกัน คือ
1. การวิเคราะห์ ระบบด้ วยวิธีเชิ งวัตถุ (Object-Oriented Analysis: OOA)
2. การออกแบบระบบด้ วยวิธีเชิ งวัตถุ (Object-Oriented Design: OOD)
3. การเขียนโปรแกรมเชิ งวัตถุ (Object-Oriented Programming: OOP)
วิธีการพัฒนาระบบ มี 2 วิธี
2. วิธีการพัฒนาระบบเชิ งวัตถุ (The Object-Oriented Approach) จัดเป็ นวิธีใหม่ ของ
การพัฒนาระบบ
ระยะที่ 5 Maintenence Phase
 นักวิเคราะห์และออกแบบระบบและทีมงานทดสอบโปรแกรม
 ผูใ้ ช้ตรวจสอบว่าโปรแกรมทางานตามที่ตอ
้ งการ
 ถ้าเกิดข้อผิดพลาดของโปรแกรม ให้ปรับปรุ งแก้ไข
 เมื่อทดสอบโปรแกรมแล้ว โปรแกรมไม่เป็ นไปตามความ
ต้องการ อาจต้องแก้ไขปรับปรุ งใหม่
 การบารุ งรักษา ส่ วนใหญ่เป็ นการแก้ไขโปรแกรมหลังจากใช้
งานแล้ว
Model การพัฒนาซอฟต์ แวร์









Waterfall
Adapted Waterfall
Evolutionary
Incremental
Spiral
Rapid Prototype
Rapid Application Development (RAD)
Joint Application Development (JAD)
Relational Unified Process (RUP)
Waterfall Model
Adapted Waterfall Model
Adapted Waterfall Model พัฒนามาจากแบบ Waterfall
โดยในแต่ละขัน
้ ตอนสามารถแก ้ไขข ้อผิดพลาดหรือสามารถย ้อนกลับ
ได ้
Evolutionary Model
Evolutionary Model จะพัฒนาระบบงานจนเสร็ จสิ้ นในVersion ที่ 1 ก่อน
จากนั้นจะพิจารณาถึงข้อดีขอ้ เสี ยใน Version ที่ 1 และนาข้อดีขอ้ เสี ย
เหล่านั้นมาพัฒนาระบบในVersion ที่ 2 และ Version ต่อ ๆ ไป
Incremental Model
Incremental Model จะมีลกั ษณะคล้ายคลึงแบบ Evolutionary แต่มีขอ้ แตกต่างกัน
ตรงที่ตวั Product (ระบบ) ที่พฒั นาขึ้นจะเป็ นส่ วนแรกเท่านั้น และพัฒนาในส่ วนที่ 2
และส่ วนอื่น ๆ เพิ่มเติมเพื่อ Product (ระบบ) ที่สมบูรณ์
Spiral Model
เหมาะกับการพัฒนาซอฟต์แวร์ขนาดใหญ่
- ทาแต่ละขั้นตอนหลายรอบตามความต้องการของผูใ้ ช้
- แต่ละขั้นตอนต้องทาต้นแบบ
- มีการวิเคราะห์ความเสี่ ยงทุกขั้นตอน
- มีลก
ั ษณะเป็ นวงจรวิเคราะห์-ออกแบบ-พัฒนา-ทดสอบ (AnalysisDesign-Implementation-Testing) และจะวนกลับมาในแนวทางเดิมไป
เรื่ อย ๆ จนกระทัง่ ได้ Product ที่สมบูรณ์
- เหมาะสาหรับระบบงานที่มีโอกาสเปลี่ยนแปลงบ่อยเนื่องจากในแต่ละเฟส
นั้นจะมีการวิเคราะห์ความต้องการใหม่ และวิเคราะห์ความเสี่ ยงว่าจะทา
การพัฒนาต่อไปอีกหรื อไม่ หรื อจะเพียงพอแล้วกับเฟสนี้เท่านั้น
-
Spiral Model
Rapid Prototype Model
- ใช้ในกรณี ที่ Requirement ไม่ชดั เจน
- สร้าง Rapid Prototype ในการหา Requirement ที่ตอ้ งการจริ ง ๆ เพื่อสร้าง
ความมัน่ ใจระหว่างลูกค้าและผูพ้ ฒั นา
- ลักษณะของ Prototype
- นาข้อมูลที่เก็บได้มาสร้างซอฟต์แวร์แบบไม่ละเอียด
- มีการสร้างหน้าจอผูใ้ ช้ การป้ อนข้อมูลเข้า การแสดงผลข้อมูล
Rapid Application Development
- การพัฒนาแอพพลิเคชัน่ อย่างรวดเร็ วโดยกระบวนการที่สาคัญ และใช้
เครื่ องมือสนับสนุน เช่น CASE Tools
- เน้นการลดต้นทุนและเวลา
- จาเป็ นต้องมีทีมงานขนาดเล็กที่มีความรู ้ความสามารถเฉพาะ
- การนาเทคนิค RAD มาใช้ในโครงการเพื่อมุ่งหวังพัฒนาระบบงานให้สาเร็ จ
อย่างรวดเร็ ว และใช้งานได้ภายในระยะเวลาจากัดมากกว่าที่จะให้ระบบ
สมบูรณ์แบบ หรื อมีเทคนิคที่ดีเลิศ
Joint Application Development
- เป็ นการพัฒนาแอพพลิเคชัน่ ร่ วมกัน โดยกลุ่มคนในองค์กร
ผูเ้ ชี่ยวชาญด้าน IT เข้าร่ วมประชุมเชิงปฏิบตั ิการ
- จุดประสงค์ คือ เพื่อพัฒนาระบบงานที่ใช้เวลาสั้นและมีความ
สมบูรณ์ในโครงการ
- มีหอ้ งปฏิบตั ิการที่ใช้เป็ นศูนย์การทางาน
Relational Unified Process (RUP)
- เป็ นกระบวนการทางวิศวกรรมซอฟต์แวร์
- เป็ นกรรมวิธีการพัฒนาซอฟต์แวร์เชิงวัตถุ
- จุดประสงค์ เพื่อต้องการสร้างซอฟต์แวร์คุณภาพสูง ตรงตามความ
ต้องการ ภายใต้งบประมาณและระยะเวลาที่กาหนด
- เน้นการสร้างโมเดลและจัดการโมเดลด้วยภาษา UML
Relational Unified Process (RUP)
มี 4 ระยะ ประกอบด้วย
1. Inception การกาหนดขอบเขตด้วย Use case
2. Elaboration สร้างข้อกาหนดและแผนงานด้วย Use case
Diagram, Class Diagram, Sequence Diagram
3. Construction พัฒนาระบบ เขียนโปรแกรม
4. Transition วางแผนนาไปใช้
Relational Unified Process (RUP)
เทคนิควิธีและเครื่องมือในการพัฒนาระบบ



แบบจาลอง (Modeling) นาเสนอแนวความคิดหรื อกระบวนการใน
รู ปแบบของภาพ
ต้นแบบ (Prototyping) การสร้างงานในเบื้องต้น
ระบบช่วยในการออกแบบ (Computer-Aided Systems
Engnering : CASE)
่ ยการพ ัฒนาระบบ (Computer-Aided
วิศวกรรมซอฟต์แวร์ชว
้
Systems Engineering-CASE ) เป็ นเทคนิควิธท
ี ใี่ ชโปรแกรมที
ม
่ ี
ความสามารถสูงเป็ นเครือ
่ งมือ เรียกย่อๆ ว่า CASE Tools
ขอบข่ายของเครือ
่ งมือสน ับสนุนการพ ัฒนาระบบ (CASE Tool
่ ง
Framework) มี 2 ชว


Upper-CASE เป็ นเครือ
่ งมือทีช
่ ว่ ยสนับสนุนการทางานในขัน
้
ตอนต ้นๆ ของการพัฒนาระบบ ได ้แก่ ขัน
้ ตอนการวางแผน
ขัน
้ ตอนการวิเคราะห์ และขัน
้ ตอนการออกแบบระบบ
Lower-CASE เป็ นเครือ
่ งมือทีช
่ ว่ ยสนับสนุนการทางานใน
ขัน
้ ตอนสุดท ้ายในการพัฒนาระบบ ได ้แก่ ขัน
้ ตอนการออกแบบ
ขัน
้ ตอนการพัฒนาและทดสอบระบบ และขัน
้ ตอนการให ้บริการ
หลังการติดตัง้ ระบบ
คุณสมบ ัติและความสามารถของ CASE ( Facilities and
Functions)
1)
2)
3)
4)
5)
้
เครือ
่ งมือชว่ ยสร ้างแผนภาพ (Diagram Tools) ใชในการเขี
ยน
ื่ มโยงกับ
แผนภาพเพือ
่ จาลองสงิ่ ต่างๆ ของระบบซงึ่ สามารถเชอ
แบบจาลองสว่ นอืน
่ ได ้
เครือ
่ งมือชว่ ยเก็บรายละเอียดต่างๆ ของระบบ (Description
Tools)
เครือ
่ งมือชว่ ยสร ้างตัวต ้นแบบ (Prototyping Tools)
เครือ
่ งมือชว่ ยสร ้างรายงานแสดงรายละเอียดของแบบจาลอง
้
(Inquiry and Reporting) ใชในการสร
้างรายงานรายละเอียด
ต่างๆ ของแบบจาลองซงึ่ ถูกเก็บไว ้ใน Repository ได ้
เครือ
่ งมือเพือ
่ คุณภาพของแบบจาลอง (Quality Management
Tools)
คุณสมบ ัติและความสามารถของ CASE ( Facilities and
Functions)
6)
7)
8)
9)
10)
11)
ิ ใจ (Decision Support Tools)
เครือ
่ งมือสนับสนุนการตัดสน
เครือ
่ งมือชว่ ยจัดการเอกสาร (Documentation Organization
Tools)
เครือ
่ งมือชว่ ยออกแบบ (Design Generation Tools)
เครือ
่ งมือชว่ ยสร ้างโค ้ดโปรแกรม (Code Generator Tools)
เครือ
่ งมือชว่ ยทดสอบ (Testing Tools)
เครือ
่ งมือชว่ ยให ้สามารถใชข้ ้อมูลร่วมกัน (Data Sharing Tools)
ปรับปรุงกระบวนการผลิตซอฟต์ แวร์
แบบจาลองวุฒิภาวะความสามารถ
Capability Maturity Model: CMM
คิดค้นโดยสถาบันวิศวกรรมซอฟต์แวร์ คาร์ เนกีเมลอน
ใช้วด
ั ความสามารถขององค์กร หรื อ บ.พัฒนาซอฟต์แวร์
ทาให้ทราบว่าองค์กรมีวฒ
ุ ิภาวะของความสามรถเติบโต
Capability Maturity เต็มที่ในระดับใด
Capability Maturity Model:
CMM
Capability Maturity Model:
CMM
1.
The Initial Level
 เป็ นระดับที่อธิ บายถึงขั้นตอนของความเป็ นจริ งทัว่ ไป การ
สร้างโปรแกรมเป็ นไปอย่างไม่มีจุดประสงค์ ไม่มีการระบุถึง
วิธีการพัฒนา หรื อ คุณภาพงานที่ออกมาได้เป็ นระดับที่ต่า
Capability Maturity Model:
CMM
2.
The Repeatable Level
 องค์กรจะมีการกาหนดนโยบาย จัดตั้งทีมงาน และการ
บริ หารโครงการซอฟต์แวร์ เป็ นไปอย่างมีแบบแผนชัดเจน มี
การติดตามผล
 ดังนั้น ความสาเร็ จของการพัฒนาซอฟต์แวร์ โครงการหนึ่ งจึง
สามารถนาไปใช้กบั โครงการในอนาคตได้
Capability Maturity Model:
CMM
3.
The Defined Level
 สื บเนื องจากวุฒิภาวะระดับ 2 โดยมุ่งเน้น กากับ ติดตาม และ
ควบคุมกระบวนการทางานต่างๆผ่านทางระบบเอกสารที่ได้
กาหนดนิยามไว้ทุกๆขั้นตอน
 ให้ความสาคัญกับการจัดการเอกสาร (Document
Management )
Capability Maturity Model:
CMM
4.
The Managed Level
 องค์กรมีการกาหนดมาตราฐาน (Standard) เพื่อใช้เป็ น
บรรทัดฐานในการประเมินกระบวนการรวมถึง คุณภาพของ
ซอฟต์แวร์
 การวางแผน ควบคุม พยากรณ์ วัดคุณภาพของซอฟต์แวร์
เป็ นระยะ
 มุ่งเน้น ปรับปรุ งมาตรฐาน อย่างต่อเนื่ อง
Capability Maturity Model:
CMM
5.
The Optimizing Level
 เป็ นองค์กรแห่ งการเรี ยนรู ้ Learning Organization
 มีการจัดสรรทรัพยากรอย่างคุม
้ ค่า
 มีเทคโนโลยี Technology
 มีฐานองค์ความรู ้ Knowledge
 มีศก
ั ยภาพในการสร้างสรรค์นวัตกรรมใหม่ Innovation
คาถามท้ ายบท
1.จงวิเคราะห์ขอ้ ดีขอ้ เสี ยของโมเดลการพัฒนาซอฟต์แวร์ ต่อไปนี้
 Water Fall Model
 Rapid Prototype Model
 Spiral Model
 Evolutionary Model
2. หากต้องดาเนินการพัฒนาระบบสารสนเทศสักโครงการหนึ่ง อยากทราบ
ว่า นักศึกษาจะใช้วธิ ี การพัฒนาระบบวิธีใด และทาไมถึงเลือกวิธีน้ ี จงอธิบายพร้อม
เหตุผลประกอบ