Transcript วิชา ITSC2301 วิศวกรรมซอฟต์แวร์

วิชา ITSC2301
วิศวกรรมซอฟต์แวร์ (Software Engineering)
ความต้องการ (Requirement)
วิศวกรรมความต้องการ (Requirement Engineering)
แบบจาลองการวิเคราะห์ (Analysis Model)
ความต้องการ (Requirement)

ความต้องการ ถือเป็ นวัตถุดบิ สาคัญในการผลิตซอฟต์แวร์ เพือ่ สร้างข้อกาหนด
ความต้องการของลูกค้า เพือ่ ให้ซอฟต์แวร์ทถ่ี กู พัฒนาขึน้ ตรงกับความต้องการ
ทีแ่ ท้จริง
จาแนกความต้องการด้านซอฟต์แวร์ได้เป็ น 2 ระดับ คือ
1. ความต้องการของผูใ้ ช้ (User Requirement)
แสดงถึงความคาดหวัง ในบริการ หรือการทางานทีไ่ ด้จากระบบและเงือ่ นไขที่
ระบบจะต้องทาตาม ถือเป็ นความต้องการในระดับสูงสุด
ความต้องการ (Requirement)
2. ความต้องการด้านระบบ (System Requirement)
เป็ นการกาหนดการทางาน ฟงั ก์ชนั และบริการต่างๆ ของระบบในระดับ
รายละเอียด และจัดทาเป็ นข้อกาหนดหน้าทีข่ องระบบ (Functional
Specification)
ความต้องการด้านซอฟต์แวร์ มีความสัมพันธ์อย่างมากกับความต้องการ
ของระบบ เพราะเป็ นการรวบรวมคุณสมบัติ ด้านเทคนิคของซอฟต์แวร์
ทีแ่ สดงถึงคาสังและบริ
่
การทีซ่ อฟต์แวร์สามารถทาได้ภายใต้ระบบหนึ่งๆ
ประเภทของความต้องการด้านซอฟต์แวร์

ความต้องการด้านซอฟต์แวร์ แบ่งออกเป็ น 3 ประเภท ได้แก่
 ความต้องการทีเ่ ป็ นหน้าทีห
่ ลัก
(Functional Requirement)
 ความต้องการทีไ่ ม่ใช่หน้าทีห
่ ลัก (Non- Functional Requirement)
 ความต้องการด้านธุรกิจ (Domain Requirement)
ประเภทของความต้องการด้านซอฟต์แวร์
1. Functional Requirement
เป็ นความต้องการทีเ่ ป็ นหน้าทีห่ ลัก ซึง่ ทาหน้าทีใ่ ดๆ ตามทีก่ าหนดไว้ในส่วน
การทางานหรือบริการทีซ่ อฟต์แวร์นนั ้ ควรมี
2. Non-Functional Requirement
เป็ นความต้องการทีไ่ ม่เกีย่ วข้องโดยตรงกับหน้าที่ หรือฟงั ก์ชนั หลักของ
ระบบ เช่น ความต้องการด้านผลิตภัณฑ์ ความต้องการขององค์กร และ
ความต้องการจากปจั จัยภายนอก เช่น การทางานร่วมกัน ด้านกฎหมาย และ
ด้านจริยธรรม
ประเภทของความต้องการด้านซอฟต์แวร์
3. Domain Requirement
เป็ นความต้องการทีเ่ กีย่ วข้องกับงานหลักของระบบธุรกิจ ทีต่ อ้ งการ
ซอฟต์แวร์มาสนับสนุนโดยเฉพาะ ซึง่ อาจเป็ นเงือ่ นไขของฟงั ก์ชนั ใดๆ หรือ
เงือ่ นไขทีใ่ ช้คานวณหาผลลัพธ์ใดๆ ของระบบ
เอกสารความต้องการด้านซอฟต์แวร์

เอกสารความต้องการด้านซอฟต์แวร์ (Software Requirement Document)
เรียกได้อกี อย่างหนึ่งว่า “ข้อกาหนดความต้องการซอฟต์แวร์” (Software
Requirement Specification : SRS) เป็ นเอกสารข้อกาหนดความต้องการ
อย่างเป็ นทางการ ทีจ่ ะบอกให้ทมี พัฒนาซอฟต์แวร์ทราบว่าต้องพัฒนา
อะไรบ้าง
รายละเอียดในเอกสารนัน้ ขึน้ อยูก่ บั ชนิดของระบบทีจ่ ะทาการพัฒนา
และกระบวนการทีใ่ ช้ เพือ่ ความเข้าใจตรงกันของผูท้ เ่ี กีย่ วข้อง IEEE ได้
กาหนดโครงสร้างของเอกสารไว้
เอกสารความต้องการด้านซอฟต์แวร์
IEEE ได้กาหนดโครงสร้างของเอกสาร ดังนี้
1.บทนา –วัตถุประสงค์ ,ขอบเขต,นิยาม,สรุป
2. รายละเอียดทัวไป
่ –มุมมอง, ฟงั ก์ชนั , คุณสมบัติ
3.ข้อกาหนดความต้องการ –หน้าทีห่ ลัก ไม่ใช่หน้าทีห่ ลัก
4.ภาคผนวก
5.ดัชนี
วิศวกรรมความต้องการ

วิศวกรรมความต้องการ (Requirement Engineering) หมายถึง กระบวนการที่
จะทาให้วศิ วกรรมซอฟต์แวร์ เข้าใจและเข้าถึงความต้องการของลูกค้าได้อย่าง
แท้จริง ด้วยการสกัดความต้องการ ตรวจสอบ และนิยามความต้องการ เพือ่ นาไป
สร้างเป็ นข้อกาหนดความต้องการด้านระบบหรือซอฟต์แวร์ ทีจ่ ะใช้เป็ นจุดเริม่ ต้น
ในการพัฒนาระบบในขัน้ ตอนต่อไป [Jawadekar, 2004] นอกจากนี้ วิศวกรรม
ความต้องการยังรวมไปถึงกระบวนการควบคุมการเปลีย่ นแปลงของความต้องการ
ทีจ่ ะเกิดขึน้ ด้วย เรียกว่า “การจัดการความต้องการ (Requirement
Management)” ดังนัน้ การวิศวกรรมความต้องการจึงช่วยให้ซอฟต์แวร์ทผ่ี ลิต
ออกมา สามารถแก้ปญั หาหรือช่วยสนับสนุนการทางานของลูกค้าได้อย่างถูกต้อง
ตรงตามความต้องการทีแ่ ท้จริง
วิศวกรรมความต้องการ

เป้าหมายของวิศวกรรมความต้องการ ก็คอื การสร้างและบารุงเอกสาร
ข้อกาหนดความต้องการ ทัง้ ทางด้านระบบและด้านซอฟต์แวร์ ให้เป็ น
เอกสารทีม่ คี ุณภาพทีส่ ดุ
งานย่อยของงานวิศวกรรมความต้องการ


งานย่อยในกระบวนการด้านวิศวกรรมความต้องการ แบ่งเป็ น 7 ด้าน ได้แก่
การเริม่ ต้นวิเคราะห์ (Inception) การเจาะลึกความต้องการ (Elicitation) การ
ขยายรายละเอียด (Elaboration) การเจรจาต่อรอง (Negotiation) การจัดทา
ข้อกาหนด (Specification) และการจัดการความต้องการ (Requirement
Management)
งานบางอย่างสามารถทาไปพร้อมๆ กันแบบขนานได้ และทุกงานต้องปรับให้
เข้ากับความจาเป็ นของโครงการ เพือ่ ให้บรรลุถงึ สิง่ ทีล่ กู ค้าต้องการอย่าง
แท้จริง
งานย่อยของงานวิศวกรรมความต้องการ

การเริม่ ต้นวิเคราะห์ (Inception)
วิศวกรซอฟต์แวร์จะตัง้ คาถามเปิด เพือ่ ทาความเข้าใจพืน้ ฐานในปญั หา และ
ทางแก้ปญั หา รวมถึงการจัดสร้างการสือ่ สารทีม่ ปี ระสิทธิภาพกับบุคลากรที่
ต้องการทางแก้ปญั หา และสร้างความร่วมมือระหว่างลูกค้ากับผูพ้ ฒ
ั นาระบบ
งานย่อยของงานวิศวกรรมความต้องการ

การเจาะลึกความต้องการ (Elicitation)
ถามความต้องการของลูกค้า และผูใ้ ช้งานระบบ ว่าต้องการอะไร เป้าหมาย
ของระบบคืออะไร ปญั หาทีพ่ บในการทางานนี้คอื
- ปญั หาของการหาขอบเขตระบบ (Problem of Scope)
- ปญั หาของการทาความเข้าใจ (Problem of Understanding)
- ปญั หาการไม่คงทน (Problem of volatility)
เทคนิ คการเก็บรวบรวมความต้องการ
เทคนิคทีใ่ ช้
1. การสัมภาษณ์ (Interview) นิยมใช้มากทีส่ ดุ
2. การแสดงลาดับเหตุการณ์ (Scenario) เตรียมคาถามตามลาดับงานของผูใ้ ช้
3. สร้างต้นแบบ (Prototype) เช่น ออกแบบจอภาพบนกระดาษ เพือ่ ทดสอบการ
ยอมรับความต้องการในเบือ้ งต้น
4. การประชุม (Meeting) เป็ นการเรียกกลุ่มบุคคลทีเ่ กีย่ วข้องมาประชุม เพือ่ ขอ
ความคิดเห็นและความต้องการ
5. การสังเกต (Observation) โดยตรวจสอบสภาพแวดล้อมการท างานของผูใ้ ช้
เป็ นวิธที ด่ี แี ต่ค่าใช้จา่ ยสูง
งานย่อยของงานวิศวกรรมความต้องการ

การขยายความรายละเอียด (Elaboration)
งานขัน้ นี้คอื การนาสารสนเทศทีไ่ ด้จากลูกค้า มาขยายและแจกแจง
รายละเอียดเพิม่ เติม กิจกรรมนี้มงุ่ จะพัฒนาแบบจาลองทางเทคนิคทีล่ ะเอียด
ของหน้าทีก่ ารทางาน รวมถึงลักษณะและข้อจากัดของซอฟต์แวร์
การขยายความรายละเอียด (Elaboration)
กระบวนการ
 การแบ่งกลุ่มความต้องการ (Requirement Classification) เป็ น functional ,
non-functional , product & process หรืออาจแบ่งกลุ่มตามลาดับความสาคัญ
ตามขอบเขต หรือตามการเปลีย่ นแปลงความต้องการ
 การสร้างแบบจาลองความต้องการ (Requirement Modeling) เป็ นแบบจาลอง
แนวคิด เพือ่ จาลองความต้องการ ให้เห็นภาพรวมความต้องการทีมงานเข้า
ใจความต้องการได้ตรงกัน ชีใ้ ห้เห็นข้อผิดพลาดและแก้ไขข้อผิดพลาดนัน้
การขยายความรายละเอียด (Elaboration)


การออกแบบสถาปตั ยกรรม (Architectural Design) แสดงให้ผใู้ ช้มองเห็น
ถึง คอมโพเน้นท์ ทีใ่ ช้สนับสนุน และรองรับความต้องการส่วนใดของผูใ้ ช้
การจัดสรรความต้องการ (Requirement Allocation)จัดสรรความต้องการ
ให้เข้ากับองค์ประกอบแต่ละส่วนของซอฟต์แวร์ เพือ่ นาไปวิเคราะห์ ในระดับ
รายละเอียดเพิม่ มากขึน้
งานย่อยของงานวิศวกรรมความต้องการ

การเจรจาต่อรอง (Negotiation)
ลูกค้ามักต่อรองขอมากกว่าทีร่ ะบบจะทาสาเร็จ นักวิศวกรความต้องการต้อง
ประสานความขัดแย้งเหล่านี้ผา่ นกระบวนการเจรจาต่อรองกับลูกค้า และ
ปรับเปลีย่ นความต้องการบางส่วน เพือ่ ให้ทกุ ฝา่ ยบรรลุความพอใจ
งานย่อยของงานวิศวกรรมความต้องการ

การจัดทาข้อกาหนด (Specification)
จัดทาเอกสาร เป็ นการรวบรวมข้อกาหนด เป็ นต้นแบบของโปรแกรม การ
จัดทาข้อกาหนด ทีบ่ ่งบอกถึงคุณลักษณะของซอฟต์แวร์ โดยเอกสารเหล่านี้
จะต้องสามารถตรวจสอบ ประเมินค่า และยอมรับได้ จาเป็ นต้องมีความ
ยืดหยุน่ โดยเฉพาะสาหรับระบบขนาดใหญ่
การจัดทาข้อกาหนด (Specification)
เอกสารทีเ่ กีย่ วข้อง
1. เอกสารนิยามระบบ เป็ นเอกสารทีถ่ กู จัดทาขึน้ จากมุมมองของผูใ้ ช้ โดยแสดง
ถึงรายการความต้องการด้านระบบ
2. เอกสารข้อกาหนดความต้องการด้านระบบ ดาเนินงานโดยวิศวกรระบบ มัก
ถูกจัดทาก่อนข้อ 3
3. เอกสารข้อกาหนดความต้องการด้านซอฟต์แวร์ ระบุถงึ หน้าทีข่ องซอฟต์แวร์
ซึง่ เป็ นข้อตกลงขัน้ พืน้ ฐานของทีมงานกับผูใ้ ช้
งานย่อยของงานวิศวกรรมความต้องการ

การตรวจรับ (Validation)
ผลิตผลงานทีเ่ ป็ นผลลัพธ์ของวิศวกรรมความต้องการ จะถูกประเมินในแง่
คุณภาพระหว่างขัน้ ตอนการตรวจรับ เป็ นการทบทวนข้อกาหนด เพือ่ ให้
มันใจว่
่ าทุกๆ ความต้องการได้ระบุไว้อย่างไม่คลุมเครือ
โดยทีมทบทวนประกอบด้วย นักวิศวกรซอฟต์แวร์ ลูกค้าผูใ้ ช้งาน และผูม้ ี
ส่วนได้สว่ นเสียในธุรกิจอื่นๆ ทาหน้าทีต่ รวจสอบข้อกาหนด เพือ่ มองหา
ข้อผิดพลาดในเนื้อหาหรือการตีความ
การตรวจรับ (Validation)
ลักษณะทีด่ ขี องความต้องการ
1. มีความเทีย่ งตรง (validity)
2. มีความสอดคล้อง (consistency)
3. มีความครบถ้วนสมบูรณ์ (completeness)
4. มีความเป็ นไปได้ (feasibility)
5. สามารถพิสจู น์ได้ ( verifiability)
การตรวจรับ (Validation)
เทคนิคการตรวจสอบ
1. การทบทวนความต้องการ (requirement review) โดยมีการตรวจสอบ
เอกสารอย่างละเอียด เพือ่ หาข้อผิดพลาดตามลักษณะต่างๆ
2. การจัดทาต้นแบบ (prototyping) ของระบบและสาธิตให้ผใู้ ช้ดู เป็ นเทคนิคที่
ใช้เงินทุนสูง แต่ได้ผลลัพธ์ทด่ี ี
3. การสร้างแบบทดสอบ (test-case generation) โดยนาแบบทดสอบนัน้ ไป
ออกแบบหรือพัฒนาระบบขึน้ ใช้ ถ้าทาได้ยาก ควรพิจารณาความต้องการนัน้
ใหม่ มักใช้กบั การพัฒนาซอฟต์แวร์แบบ Extreme Programming
งานย่อยของงานวิศวกรรมความต้องการ

การจัดการความต้องการ (Requirement Management)
ความต้องการในระบบมักเปลีย่ นแปลงไปตลอดช่วงชีวติ ของระบบ การ
จัดการความต้องการเป็ นชุดของกิจกรรมทีช่ ่วยให้ทมี งานกาหนดกลไกใน
การควบคุมและติดตามความสาเร็จและการเปลีย่ นแปลงความต้องการ ณ
เวลาใดเวลาหนึ่งขณะทีโ่ ครงการดาเนินไป
การจัดการความต้องการ (Requirement Management)
สาเหตุของการเปลีย่ นแปลงความต้องการ
1. มีผใู้ ช้หลายกลุ่มซึง่ มีความต้องการต่างกัน จึงมีความขัดแย้งกัน จาเป็ นต้องมี
การปรับสมดุลความต้องการใหม่
2. เกิดความขัดแย้งระหว่างผูใ้ ช้ทจ่ี า่ ยเงินลงทุน กับผูใ้ ช้ทเ่ี ป็ นผูใ้ ช้ระบบโดยตรง
3. มีการเปลีย่ นสภาพแวดล้อมทางธุรกิจและเทคโนโลยีภายหลังมีการติดตัง้ ใช้
ระบบงาน
การจัดการความต้องการ (Requirement Management)

กระบวนการ
1. จาแนกความต้องการทีเ่ ปลีย่ นแปลงและความต้องการทีไ่ ม่เปลีย่ นแปลง
2. วางแผนการจัดการความต้องการ โดยระบุความเป็ นเอกลักษณ์ให้กบั ทุก
ความต้องการ กาหนดกิจกรรมการประเมินผล กาหนดความสัมพันธ์ของ
ความต้องการแต่ละรายการและใช้ Case Tool เข้าช่วยจัดการความต้องการ
3. จัดการกับการเปลีย่ นแปลงความต้องการ เพือ่ ให้การเปลีย่ นแปลงทัง้ หมด
ทีเ่ กิดขึน้ มีความสอดคล้องกัน โดยอาศัยหลักการจัดการโครงแบบของระบบ
แบบจาลองการวิเคราะห์ (Analysis Model)
แบบจาลอง คือ สัญลักษณ์ทใ่ี ช้จาลองข้อเท็จจริงต่างๆ ที่
เกิดขึน้ ในระบบ เป็ นแผนภาพทีแ่ สดงให้เห็นในแต่ละมุมมอง
แบบจาลองการวิเคราะห์ คือ แบบจาลองทีเ่ ขียนขึน้ จากข้อกาหนด
ความต้องการของระบบ สะท้อนให้เห็นถึงหน้าทีก่ ารทางานของ
ระบบด้านต่างๆ และจะถูกนาไปใช้ในระยะการออกแบบต่อไป
แบบจาลองการวิเคราะห์ (Analysis Model)
ประเภท
 แบบจาลองตามแนวทางเชิงโครงสร้าง (Structured Analysis) – Process
Model(DFD) + Data Model (ER)
 แบบจาลองตามแนวทางเชิงวัตถุ (Object Oriented Analysis) – UML
(Unified Modeling Language)
แบบจาลองเชิงโครงสร้าง (Structured Analysis)


พิจารณาข้อมูล (Data) และกระบวนการ (Process) ทีเ่ ปลีย่ นรูปข้อมูล วัตถุขอ้ มูล
ถูกจาลองในลักษณะทีก่ าหนด แอตทริบวิ ส์และความสัมพันธ์ กระบวนการที่
จัดการกับข้อมูลถูกจาลองในลักษณะทีแ่ สดงว่าสามารถเปลีย่ นข้อมูลทีเ่ ป็ นเป็ น
วัตถข้อมูลผ่านระบบได้อย่างไร
แบ่งออกเป็ น 2 ชนิด คือ
 แบบจาลองกระบวนการ (Process
Model) จาลองขัน้ ตอนการทางานของระบบ - DFD
 แบบจาลองข้อมูล (Data Model) จาลองโครงสร้างข้อมูลทัง้ หมดในระบบ - ERD
แบบจาลองกระบวนการ (Process Model)


แผนภาพกระแสข้อมูล (Data Flow Diagram)
แผนภาพทีแ่ สดงถึงทิศทางการไหลของข้อมูลทีม่ อี ยูใ่ นระบบ จากกระบวนการทางาน
หนึ่งไปอีกกระบวนการหนึ่ง หรือไปยังส่วนอื่นทีเ่ กีย่ วข้อง เช่น แหล่งจัดเก็บข้อมูล (Data
Store) ผูท้ เ่ี กีย่ วข้องทีอ่ ยูน่ อกระบบ (External Agent)
ประเภทของแผนภาพกระแสข้อมูล
- แผนภาพกระแสข้อมูล เชิงตรรกะ (Logical DFD) – แสดงกระบวนการของระบบใน
ระดับแนวคิด (Conceptual) เท่านัน้
- แผนภาพกระแสข้อมูล เชิงกายภาพ (Physical DFD) – แสดงรายละเอียดภายใน
กระบวนการ เช่น ชือ่ กระบวนการ วิธกี ารทางาน แหล่งกาเนิด และปลายทาง เป็ นต้น
Context Diagram

แผนภาพกระแสข้อมูล
ระดับบนสุดทีแ่ สดง
ภาพรวมการทางานของ
ระบบทีม่ คี วามสัมพันธ์กบั
สภาพแวดล้อมนอกระบบ
ตัวอย่าง DFD
ตัวอย่าง DFD
แบบจาลองข้อมูล (Data Model)

แผนภาพแสดงความสัมพันธ์ของข้อมูล (Entity Relationship Diagram : ERD)
เป็ นแผนภาพสาหรับจาลองข้อมูล ซึง่ จะประกอบด้วย Entity และ
ความสัมพันธ์ของข้อมูล (Relationship) ทีเ่ กิดขึน้ ทัง้ หมดในระบบ
แบบจาลองเชิงวัตถุ (Object Oriented Analysis)


มุง่ ทีน่ ิยามของคลาสและลักษณะทีค่ ลาสทางานร่วมกัน แทนทีเ่ ราจะมอง
ปญั หาในลักษณะอินพุต โพรเซส เอาท์พตุ แบบดัง้ เดิม ซึง่ เป็ นลักษณะของ
กระแสข้อมูล เราจะมองปญั หาในแง่ของโครงสร้างข้อมูลตามลาดับชัน้
แบบจาลองเชิงวัตถุ UML (Unified Modeling Language) มี 9 แผนภาพ