290342 Software Development Process

290342 Software Development Process บทที่ 4วิศวกรรมระบบ อ.ธารารัตน์ พวงสุวรรณ คณะวิทยาศาสตร์และศิลปศาสตร์ มหาวิทยาลัยบูรพา วิทยาเขตสารสนเทศจันทบุรี

เนื้อหา • กิจกรรมหลักของวิศวกรรมระบบ • วิศวกรรมความต้องการ • กระบวนการวิศวกรรมความต้องการ • โมเดลการวิเคราะห์ • แบบจำลองตามแนวทางเชิงโครงสร้าง • แบบจำลองตามแนวทางเชิงวัตถุ

องค์ประกอบของวิศวกรรมซอฟต์แวร์องค์ประกอบของวิศวกรรมซอฟต์แวร์ ส่วนที่ 1 วิศวกรรมระบบ (System Engineering) ส่วนที่ 2 วิศวกรรมการผลิต (Development Engineering)

วิศวกรรมระบบ (System Engineering) • วิศวกรรมระบบ หมายถึง กระบวนการศึกษาและวิเคราะห์ระบบที่มีความสลับซับซ้อน เพื่อสนับสนุนการทำงานในส่วนของวิศวกรรมซอฟต์แวร์ กิจกรรมของวิศวกรรมระบบ จะถูกดำเนินการไปพร้อมๆ กับกิจกรรมของวิศวกรรมซอฟต์แวร์

วิศวกรรมการผลิต วิศวกรรมการผลิต (Development Engineering)ซึ่งเป็นกระบวนการแปรสภาพความต้องการของระบบ (System Requirements) ให้กลายเป็นซอฟต์แวร์อันเป็นเป้าหมายสำคัญทางด้านวิศวกรรมซอฟต์แวร์

กิจกรรมหลักของวิศวกรรมระบบ กิจกรรมหลักของวิศวกรรมระบบ มีดังนี้ กำหนดวัตถุประสงค์ของระบบ กำหนดขอบเขตของระบบ แบ่งระบบออกเป็นส่วนๆ ตามฟังก์ชันงานหรือคุณสมบัติระบบ พิจารณาความสัมพันธ์ของส่วนประกอบต่างๆ ที่เกี่ยวข้องทั้งหมด กำหนดความสัมพันธ์ของปัจจัยนำเข้า ประมวลผล และผลลัพธ์

กิจกรรมหลักของวิศวกรรมระบบ พิจารณาปัจจัยที่มีส่วนเกี่ยวข้องในระบบ ไม่ว่าจะเป็นฮาร์ดแวร์ ซอฟต์แวร์ ฐานข้อมูล หรือแม้แต่ผลิตภัณฑ์ซอฟต์แวร์อื่นๆ เป็นต้น กำหนดความต้องการในส่วนของการดำเนินการและฟังก์ชันงานทั้งระบบ สร้างแบบจำลอง เพื่อใช้วิเคราะห์และพัฒนาให้สอดคล้องกับแบบจำลองซอฟต์แวร์ นำเสนอและแลกเปลี่ยนข้อคิดเห็นกับผู้ที่เกี่ยวข้องกับระบบ

วิศวกรรมความต้องการ(Requirement Engineering) • เป็นการสกัดความต้องการ ตรวจสอบ และนิยามความต้องการเพื่อไปสร้างเป็นข้อกำหนดความต้องการด้านระบบหรือซอฟต์แวร์ • เป้าหมายคือ สร้างและบำรุงรักษาเอกสารข้อกำหนดความต้องการให้เป็นเอสารที่มีคุณภาพมากที่สุด • ข้อกำหนดความต้องการที่ไม่ถูกต้องจึงส่งผลให้ซอฟต์แวร์ไม่ตรงกับความต้องการของผู้ใช้

วิศวกรรมความต้องการ(Requirement Engineering) • User Requirement • System Requirement

กระบวนการวิศวกรรมความต้องการกระบวนการวิศวกรรมความต้องการ • รวมอยู่ในระยะการวิเคราะห์ความต้องการของกระบวนการผลิตซอฟต์แวร์ • มีลักษณะการทำซ้ำในแต่ละระยะเพื่อให้เป็นเอกสารความต้องการที่มีประสิทธิภาพ

กระบวนการวิศวกรรมความต้องการกระบวนการวิศวกรรมความต้องการ ความต้องการประเภทต่างๆ แบบจำลองความต้องการ ข้อกำหนดความต้องการ เอกสารข้อกำหนดความต้องการ

กระบวนการวิศวกรรมความต้องการกระบวนการวิศวกรรมความต้องการ • สกัดความต้องการ (Requirement Elicitation) • วิเคราะห์ความต้องการ(Requirement Analysis) • กำหนดความต้องการ(Requirement Specification) • ตรวจสอบความต้องการ (Requirement Validation)

เอกสารข้อกำหนดความต้องการเอกสารข้อกำหนดความต้องการ แบ่งเป็น 3 ประเภท • เอกสารนิยามระบบ (System Definition Document) • เอกสารข้อกำหนดความต้องการด้านระบบ (System Requirement Specification) • เอกสารข้อกำหนดความต้องการด้านซอฟต์แวร์ (Software Requirement Specification : SRS)

เอกสารความต้องการด้านซอฟต์แวร์เอกสารความต้องการด้านซอฟต์แวร์ • เอกสารความต้องการด้านซอฟต์แวร์ Software Requirement Document • หรือ ข้อกำหนดความต้องการด้านซอฟต์แวร์ Software Requirement Specification: SRS เอกสารความต้องการไม่ใช่เอกสารประกอบการออกแบบแต่เป็นเอกสารของกลุ่มความต้องการที่กล่าวว่าระบบควรต้องทำอะไรบ้าง จึงเป็นเสมือนสัญญาหรือข้อตกลงระหว่างผู้พัฒนากับผู้ว่าจ้าง เพื่อให้ทราบถึงขอบเขตในการพัฒนา

เอกสารความต้องการด้านซอฟต์แวร์เอกสารความต้องการด้านซอฟต์แวร์ • เอกสารความต้องการด้านซอฟต์แวร์ ต้องมีรูปแบบที่เป็นทางการ เพื่อความเข้าใจตรงกัน ดังนั้น IEEE และกระทรวงกลาโหมของสหรัฐ จึงได้กำหนดโครงสร้างของเอกสารไว้ดังนี้ (Davis, 1993)

โครงสร้างของเอกสาร SRS • ข้อกำหนดความต้องการ (Specification Requirement) • - กล่าวถึงความต้องการที่เป็นหน้าที่หลัก • และไม่ใช่หน้าที่หลัก • - ข้อบังคับในการออกแบบ และการ • แสดงผล เป็นต้น • บทนำ (Introduction) - วัตถุประสงค์ของผลิตภัณฑ์ - ขอบเขตของผลิตภัณฑ์ - นิยาม คำย่อ หรือ อักษรย่อ - เอกสารอ้างอิง - สรุปส่วนอื่น ๆ ของเอกสาร • รายละเอียดทั่วไป (General Description) - มุมมองเกี่ยวกับผลิตภัณฑ์ - ฟังก์ชันของผลิตภัณฑ์ - คุณสมบัติของผู้ใช้ - ข้อบังคับทั่วไป - สมมุติฐานและส่วนเพิ่มเติม • ภาคผนวก (Appendices) • ดัชนี (Index)

เอกสาร SRS ที่ดัดแปลงมาจาก IEEE830,1993[Javadekar,2005]

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

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

ความสำคัญของการวิเคราะห์ความสำคัญของการวิเคราะห์ • เพื่อให้ทราบถึงความเป็นไปและเป็นมาของระบบ และขั้นตอนในการปฏิบัติงานของระบบ • เพื่อการออกแบบระบบใหม่ที่ตรงตามความต้องการของผู้ใช้ให้มากที่สุด

ความสำคัญของการวิเคราะห์ (ต่อ) • โมเดลที่มักนำเอามาพิจารณาและวิเคราะห์ระบบ • Context Diagram • Data Flow Diagram • E-R Diagram • System Flow Chart / Flow Chart • etc. • ความผิดพลาดของโปรแกรมเมอร์มากมายที่ออกแบบระบบโดยไม่ผ่านการวิเคราะห์ ก่อให้เกิดผลเสียมากมาย เช่น เวลา, ค่าใช้จ่าย

แบบจำลองการวิเคราะห์ (Analysis Model) แบบจำลองตามแนวทางเชิงโครงสร้าง (Structured Analysis)ProcessModel(DFD) + DataModel (ER) แบบจำลองตามแนวทางเชิงวัตถุ (Object Oriented Analysis)UML(Unified Modeling Language)

แบบจำลองเชิงโครงสร้าง (Structure Analysis) พิจารณาข้อมูล (Data) และกระบวนการ (Process) แบ่งออกเป็น 2 ชนิด คือ แบบจำลองกระบวนการ (Process Model) จำลองขั้นตอนการทำงานของระบบ - DFD แบบจำลองข้อมูล (Data Model) จำลองโครงสร้างข้อมูลทั้งหมดในระบบ - ERD

แผนภาพกระแสข้อมูล (DataFlowDiagram) • DFD คือ เป็นแผนภาพที่บอกถึงรายละเอียดของระบบ โดยเฉพาะข้อมูล และผังการไหลของข้อมูล • สิ่งที่ DFD บอกเรา • ข้อมูลมาจากไหน • ข้อมูลไปที่ใด • ข้อมูลเก็บที่ใด • เกิดเหตุการณ์ใดกับข้อมูลบ้าง

แบบจำลองกระบวนการ (Process Model) แผนภาพกระแสข้อมูล (Data Flow Diagram) แผนภาพที่แสดงถึงทิศทางการไหลของข้อมูลที่มีอยู่ในระบบ จากกระบวนการทำงานหนึ่งไปอีกกระบวนการหนึ่ง หรือไปยังส่วนอื่นที่เกี่ยวข้อง เช่น แหล่งจัดเก็บข้อมูล (Data Store) ผู้ที่เกี่ยวข้องที่อยู่นอกระบบ (External Agent)

วัตถุประสงค์ของ DFD • เป็นแผนภาพสรุปรวมข้อมูลทั้งหมดที่ได้จากการวิเคราะห์ • เป็นข้อตกลงร่วมกันระหว่าง SA และ User • เป็นแผนภาพที่ใช้ในการพัฒนาต่อในขั้นตอนออกแบบ • เป็นแผนภาพที่ใช้ในการอ้างอิง หรือเพื่อใช้พัฒนาต่อ • ทราบที่มาที่ไปของกระบวนการต่าง ๆ ดังนั้น DFD จึงมีความสำคัญมากต่อการพัฒนาระบบ ซึ่ง SA หรือ Programmer ไม่สามารถมองข้ามได้

ขั้นตอนการวิเคราะห์เพื่อไปสู่การออกแบบขั้นตอนการวิเคราะห์เพื่อไปสู่การออกแบบ

แผนภาพกระแสข้อมูล (Data Flow Diagram) • เป็นรูปภาพสื่อความเข้าใจง่าย • มีเพียง 4 สัญญลักษณ์ • มีลักษณะTop-Down

สัญลักษณ์ที่ใช้ใน DFD

กฎเกณฑ์การเขียนแผนภาพกระแสข้อมูลกฎเกณฑ์การเขียนแผนภาพกระแสข้อมูล • สัญลักษณ์ของแผนภาพไม่สามารถเชื่อมต่อกันได้โดยตรง ซึ่งต้องมี Flow บอกทิศทางของกระแส (Flow ระบุข้อมูล) • และการ Flow ทุกครั้งจะต้องผ่าน Process ก่อนทุกครั้ง (ไม่ผ่านไม่ได้) • Process = กิริยา • Flow = ข้อมูล • Boundaries, Entity= องค์กร, หน่วยงาน

แผนภาพ DFD ที่ถูกต้อง

แผนภาพ DFD ที่ไม่ถูกต้อง

ขั้นตอนการเขียน DFD 1. วิเคราะห์ให้ได้ว่าระบบประกอบไปด้วย Boundaries/Entityใดบ้างที่เกี่ยวข้อง 2. ดำเนินการออกแบบระบบในระดับหลักการ หรือ Context Diagram 3. วิเคราะห์ข้อมูลในระบบว่าควรมีข้อมูลใดบ้าง 4.วิเคราะห์กระบวนการหรือ Process ในระบบว่า ควรมี Process หลักใด และประกอบไปด้วย Process ย่อยใดบ้าง 5. ดำเนินการเขียนแผนภาพกระแสข้อมูลในระดับต่าง ๆ 6. ทำการตรวจสอบ และปรับแก้ จนได้แผนภาพที่สมบูรณ์ 7. อาจใช้ CASE Tools ช่อยในการเขียนแผนภาพ

Process • คือ กระบวนการที่ต้องทำในระบบ • โดยจะพิจารณาจากกิริยาหรือการกระทำภายในระบบเป็นหลัก • ในการเขียน Process จะต้องมีหมายเลขกำกับอยู่ด้วย เป็นลำดับชั้นไล่ไปเรื่อย ๆ เพื่อให้ทราบว่า Process ใด มาจาก Process ใด

กระบวนการ(Process) 1 ขั้นตอนการทำงาน ของระบบ Input Output

กฎของการเขียนกระบวนการกฎของการเขียนกระบวนการ ต้องไม่มีข้อมูลรับเข้าเพียงอย่างเดียว ต้องไม่มีข้อมูลออกเพียงอย่างเดียว ข้อมูลรับเข้าจะต้องเพียงพอในการสร้างข้อมูลส่งออก การตั้งชื่อ Process ต้องใช้ คำกริยา เช่น รับรายการสั่งซื้อ คำนวณคะแนนเฉลี่ย พิมพ์รายงาน เป็นต้น จำนวนกระบวนการที่ต้องทำในระบบไม่ควรมีมากน้อยเกินไป ควรอยู่ระหว่าง 2-7 (หรือ +/- 2) กระบวนการ มีหมายเลขกำกับ นำเสนอว่าทำหน้าที่อะไรไม่ลงรายละเอียด (Black Box)

เส้นทางการไหล (Data Flow) 1 คำนวณเงินเดือนสุทธิ เงินเดือน, ภาษี, ค่าประกันสังคม เงินเดือนสุทธิ พนักงาน แผนกการเงิน เส้นทางการไหลของข้อมูล (Data Flow) เป็นการสื่อสารระหว่างขั้นตอนการทำงาน (Process) ต่าง ๆ และสภาพแวดล้อมภายนอกหรือภายในระบบ โดยแสดงถึงข้อมูลที่นำเข้าในแต่ละ Process และข้อมูลที่ส่งออกจาก Process ใช้ในการแสดงถึงการบันทึกข้อมูล การลบข้อมูล การแก้ไขข้อมูลต่าง ๆ ใช้สัญลักษณ์แทนด้วยเส้นลูกศรที่ไปพร้อมกับข้อมูล ดังรูป

กฎของ Data Flow ชื่อของ Data Flow คือชื่อของข้อมูลที่ส่งโดยไม่ต้องอธิบายว่าส่งอย่างไร Data Flow ต้องมีจุดเริ่มต้นหรือสิ้นสุดที่ Process Data Flow จะเดินทางระหว่าง External Entity กับ External Entity ไม่ได้ Data Flow จะเดินทางจาก External Entity ไป Data Store ไม่ได้ Data Flow จะเดินทางจาก Data Store ไป External Entity ไม่ได้ Data Flow จะเดินทางระหว่าง Data Store กับ Data Store ไม่ได้ การตั้งชื่อต้องใช้ คำนาม ที่สื่อความหมาย เช่น ใบกำกับสินค้า ไม่ควรเขียนเส้นซ้อนทับกัน

ปัจจัยภายนอกหรือเอ็กเทอร์นัลเอ็นทิตี (External Entity) External Entity • หมายถึง บุคคล หน่วยงานในองค์กร องค์กรอื่น ๆ หรือระบบงานอื่น ๆ ที่อยู่ภายนอกขอบเขตของระบบ แต่มีความสัมพันธ์กับระบบ • โดยมีการส่งข้อมูลเข้าสู่ระบบเพื่อดำเนินงาน และรับข้อมูลที่ผ่านการดำเนินงานเรียบร้อยแล้วจากระบบ ในบางครั้งเรียก “External Agent” • กฎของ External Entities • ข้อมูลจาก External Entities หนึ่งจะวิ่งไปสู่อีก External Entities หนึ่งโดยตรงไม่ได้ (จะต้องผ่าน Process ก่อน) • การตั้งชื่อต้องใช้ คำนาม ที่สื่อความหมาย เช่น ลูกค้า • มักจัดวางด้านนอกหรือรอบแผนาภาพ

ปัจจัยภายนอกหรือเอ็กเทอร์นัลเอ็นทิตี (External Entity) นักศึกษา นักศึกษา ในบางครั้ง External Entities อาจจำเป็นต้องกระทำซ้ำ (Duplicate) เนื่องจากข้อจำกัดในด้านการเชื่อมโยง Data Flows ที่ซ้อนทับและข้ามกันไปมา จะทำให้แผนภาพดูยุ่งเหยิง ไม่เป็นระเบียบ และอ่านหรือทำความเข้าใจได้ยาก โดย External Entities ที่กระทำซ้ำสามารถทำได้โดยใช้เครื่องหมาย \(back slash) ไว้ที่มุมล่างซ้าย ดังรูป แบบปกติ แบบการทำซ้ำ

แหล่งจัดเก็บข้อมูล (Data Store) รหัส Dตัวเลข • แหล่งจัดเก็บข้อมูล (Data Store) เป็นแหล่งเก็บ / บันทึกข้อมูล เปรียบเสมือนคลังสินค้า (เทียบเท่ากับไฟล์ข้อมูล และฐานข้อมูล) โดยมีรายละเอียดและคุณสมบัติเฉพาะตัวของ สิ่งที่ต้องการเก็บ / บันทึก • กฎของ Data Store • ข้อมูลจาก Data Store หนึ่งจะวิ่งไปสู่อีก Data Store หนึ่งโดยตรงไม่ได้ (จะต้องผ่าน Process ก่อน) • ข้อมูลจาก Data Store หนึ่งจะวิ่งไป หรือ กลับจาก External Entity หนึ่งโดยตรงไม่ได้ (จะต้องผ่าน Process ก่อนเช่นกัน) • การตั้งชื่อต้องใช้ คำนาม ที่สื่อความหมาย เช่น ไฟล์ข้อมูลลูกค้า

ระดับของ DFD • ในการเขียน DFD สามารถแยกรายละเอียดของแผนภาพออกเป็นหลายระดับ เพื่อง่ายต่อการกำหนดขอบเขตในการพิจารณาและง่ายต่อการทำความเข้าใจ • ระดับของ DFD • DFD Level 0 (Context Diagram ) • DFD Level 1 • DFD Level 2 • DFD Level n

ContextDiagram • คือการออกแบบในระดับบนสุดของ DFD เป็นแผนภาพที่แสดงภาพรวมสูงสุดของระบบ • ซึ่งจะแสดงถึงสิ่งแวดล้อมของระบบและองค์ประกอบหลัก ๆ เท่านั้น • โดยที่จะมีเพียง 1 Process ซึ่งเป็นชื่อของระบบ (0) และจะไม่มี Data Store ปรากฏอยู่ใน Context Diagram โดยเด็ดขาด

การสร้างแผนภาพบริบท (Context Diagram) • หลักเกณฑ์การใช้สัญลักษณ์สร้างแผนภาพกระแสข้อมูล • Context diagram ต้องสมดุลอยู่ภายในหนึ่งหน้ากระดาษ • ชื่อของกระบวนการใน context diagram ควรเป็นชื่อของระบบงานหรือโครงงานและแสดงหมายเลขศูนย์ (0) • มีการแสดง entity และการไหลของข้อมูลที่แสดงการติดต่อระหว่างระบบกับสิ่งที่อยู่ภายนอก • ไม่มีการแสดงแหล่งจัดเก็บข้อมูล (Data Store) • ขอบเขตของระบบพิจารณาได้จากจำนวน Input/Outputทั้งหมด

ระบบทะเบียน รหัสนิสิต ผลคะแนน อาจารย์ นิสิต ผลการเรียน ตัวอย่างContext diagram

290342 Software Development Process