1.รายการปัญหา (Problem list)
เป็นส่วนที่รายงานปัญหาที่ได้มาจากเอกสารความต้องการ (Requirements document) ซึ่งเราควรจะจัดเรียงปัญหาต่างๆ ที่ได้ออกมาเป็นหมวดหมู่
2.ข้อตกลงในกิจกรรม (Agreed actions)
ส่วนนี้เป็นลิสต์ของการกระทำต่างๆ ที่จะตอบสนองต่อปัญหาที่เราเจอในกระบวนการ ซึ่งไม่เสมอไปที่จะมีการกระทำต่างๆกับแก้ปัญหาแบบ 1: 1 บางปัญหาอาจจะต้องใช้หลายการกระทำเพื่อที่จะทำให้สามารถแก้ปัญหาได้
1.เอกสารความต้องการ (Requirements document)
ส่วนนี้ควรจะเป็นเอกสารที่สมบูรณ์แล้วซึ่งถูกจัดการให้อยู่ในรูปแบบที่ตรงมาตรฐานขององค์กรนั้น
2.มาตรฐานขององค์กร (Organizational standards)
กระบวนการตรวจสอบต้องสอดคล้องกับมาตรฐานขององค์กร ดังนั้น มาตรฐานขององค์กรจึงเป็นส่วนหนึ่งของ input ของกระบวนการนี้
3.ความรู้ที่เกี่ยวกับองค์กร (Organizational knowledge)
นี่ไม่ได้เป็น input ที่สามรถสัมผัสได้ แต่เป็นส่วนที่สำคัญ บุคคลที่ทำกระบวนการ requirements validation ควรจะมีความรู้ในองค์กรที่จะใช้ระบบที่พัฒนาด้วยเพื่อประโยชน์ในการตรวจสอบความถูกต้อง
เป็นขั้นตอนสุดท้ายในกระบวนการ Requirements engineering ซึ่งมีเป้าหมายคือ เพื่อทำให้ความต้องการที่เราเก็บมาถูกต้อง โดย requirements validation จะมุ่งเน้นไปในทางการตรวจสอบ เอกสารความต้องการ (requirements document) ซึ่งรวบรวมความต้องการทุกอย่างของระบบและ ความไม่สมบูรณ์พร้อมทั้งความซ้อนทับของความต้องการถูกกำจัดไปทั้งหมดแล้ว นอกจากนี้การทำ requirements validation เราควรมีคำถามคำถามหนึ่งอยู่ในใจเสมอ นั่นคือ เราได้ความต้องการที่ถูกต้องแล้วหรือยัง เกณฑ์การตรวจสอบความต้องการมี 4 ขั้นตอนคือ
1.ความถูกต้อง(Validity)
ความต้องการต่าง ๆที่ลูกค้าระบุในเอกสารต้องตรงกับสิ่งที่ลูกค้าต้องการจริงๆ
2. ความสอดคล้อง (Consistency)
ความต้องการต่างๆ จะต้องไม่ขัดแย้งซึ่งกันและกัน
3. ความสมบูรณ์ (Completeness)
รายละเอียดต่าง ๆที่เป็นความต้องการและเงื่อนไขกฎเกณฑ์ทั้งหมด จะต้องถูกระบุอยู่ในเอกสาร
4. ความเป็นจริง (Realism)
ในทางปฏิบัติไม่มีทางใดที่จะบอกได้ว่า ความต้องการต่างๆ ทีระบุในข้อกำหนดสามารถนำมาพัฒนาระบบได้จริง
เอกสารความต้องการประกอบไปด้วย 2 ส่วนคือ
requirements definition และ requirements specification โครงสร้างที่ดีควรจัดแบ่งรายละเอียดออกเป็นบทๆ และมีการอธิบายศัพท์ต่างๆ ที่ใช้ในเอกสาร
บทที่ | รายละเอียด |
Introduction
Glossary
System model
Functional requirement definition Non- Functional requirement definition System evolution
Requirement specification | - อธิบายถึงสิ่งต่างๆ ที่จะมีในระบบ และมีการระบุประโยชน์ที่ได้รับ, หน้าที่ต่างๆ ที่มีในระบบ,เป้าหมายของการพัฒนา, วิธีการหรือยุทธวิธีที่จะนำระบบไปใช้ในองค์กร
- อธิบายศัพท์ทางเทคนิคที่มีในเอกสาร ซึ่งในการเขียนคำอธิบายจะตั้งสมติฐานว่าผู้อ่านประกอบด้วยผู้มีและไม่มีประสบการณ์
- ตัวแบบระบบซึ่งแสดงความสัมพันธ์ของระบบกับสภาพแวดล้อมภายนอก ว่าติดต่อกับองค์กรหรือระบบใดบ้าง มีกระบวนการทำงานอย่างไร - อธิบายบริการต่างๆ ที่ผู้ใช้ต้องการมีในระบบใหม่ ซึ่งอาจใช้ภาษาธรรมชาติ, แผนภูมิ หรือสัญลักษณ์ที่ผู้ใช้สามารถอ่านเข้าใจได้ง่าย
-รายละเอียดข้อจำกัดและเงื่อนไขต่างๆ ที่ระบบต้องพัฒนา เช่น เวลา ขนาดหน่วยความจำ - รายละเอียดของสมมติฐานที่คาดว่าอาจมีการเปลี่ยนแปลงในระบบ เช่น ความต้องการ, วิวัฒนาการของฮาร์ดแวร์
- ระบุรายละเอียด Functional requirement definition specification |
เอกสาร requirements document ไม่ได้เป็นเอกสารที่ใช้ในการออกแบบระบบซอฟต์แวร์ ดังนั้นจึงไม่มีการระบุรายละเอียดวิธีการออกแบบว่าต้องทำอย่างไร หากแต่เป็นสิ่งที่ระบุว่าควรมีอะไรบ้างในซอฟต์แวร์ที่กำลังพัฒนา เอกสารชุดนี้เป็นเครื่องมือสำหรับติดตามการดำเนินงานระหว่างช่วงการค้นหาความต้องการและการออกแบบในขั้นสุดท้าย ซึ่งหมายความว่าความต้องการต่างๆ จะถูกนำมาแปลงเป็นข้อมูลที่ใช้ในการออกแบบระบบและเขียนโปรแกรม
หลักการเขียนรายละเอียดที่อยู่ในเอกสารชุดนี้คือ ต้องมีความสมบูรณ์และข้อมูลต่างๆ ในเอกสารต้องไม่ขัดแย้งกัน คุณสมบัติที่ควรมีใน requirements document คือ
1.ควรมีพฤติกรรมภายนอกที่เกี่ยวข้องกับระบบ
2.ควรมีการระบุเงื่อนไขหรือข้อจำกัดภายในระบบ
3.ควรอยู่ในรูปแบบที่ง่ายสำหรับการแก้ไข
4.สามารถนำมาเป็นเครื่องมืออ้างอิงในระบบ
5.ควรมีการบันทึกรายละเอียดขั้นตอนการทำงานที่เกิดขึ้น รวมถึงวัฏจักรการพัฒนา
6.ควรมีการระบุวิธีการทำงานของระบบ เมื่อมีเหตุการณ์ที่ไม่ต้องการเกิดขึ้น
ขั้นตอนวิธีของ กระบวนการต่อรอง (requirements negotiation process) มีดังนี้คือ
1.การตัดสินใจในความต้องการ (Requirements discussion)
ความต้องการที่เป็นปัญหาจะต้องนำไปปรึกษากับผู้เกี่ยวข้องในระบบ ให้พวกเขาได้บ่งบอกถึงความต้องการนั้นๆ ในแง่มุมของเขาให้เราเข้าใจ
2.ลำดับความสำคัญของความต้องการ (Requirements prioritization)
ความต้องการที่ขัดแย้งกัน จะถูกจัดลำดับความสำคัญ เพื่อที่จะกำหนดความต้องการวิกฤต เพื่อช่วยในกระบวนการตัดสินใจ
3.ข้อตกลงของความต้องการ (Requirements agreement)
เป้าหมายของการวิเคราะห์ความต้องการของผู้ใช้ก็คือ เพื่อที่จะค้นหาปัญหาใน เอกสารความต้องการต้นแบบ (draft requirements document) ขณะดำเนินการวิเคราะห์ความต้องการต่างๆ นักวิเคราะห์ต้องพยายามทำความเข้าใจกับปัญหาต่างๆ ขององค์กร
ขั้นตอนต่างๆ ของ requirements analysis process จะมีกิจกรรมที่ต้องดำเนินการซ้ำไปซ้ำมาจนกระทั่งได้ข้อมูลที่ถูกต้องและชัดเจนที่สุด ซึ่งขั้นตอนนี้มีกิจกรรมต่างๆ ดังนี้
1. การตรวจสอบความต้องการ (Necessity checking)
สิ่งที่จำเป็นสำหรับความต้องการต่างๆ จะถูกวิเคราะห์ ซึ่งในบางกรณี ความต้องการบางอย่างอาจจะไม่ได้เกี่ยวข้องกับเป้าหมายทางธุรกิจขององค์กร
2.การตรวจสอบความสอดคล้องและสมบูรณ์ของความต้องการ (Consistency and completeness checking)
ความต้องการจะถูก ตรวจสอบ(cross-checked) สำหรับ ความสอดคล้องและความสมบูรณ์ ความสอดคล้องหมายความว่าจะต้องไม่มีความต้องการใดที่ขัดแย้งกัน ส่วนความสมบูรณ์หมายความว่า จะต้องไม่มีบริการหรือข้อกำหนดใดๆ ตกหล่นหรือขาดหายไป
3. การตรวจสอบความเป็นไปได้ (Feasibility checking)
ความต้องการจะถูกตรวจสอบ เพื่อให้แน่ใจว่า โครงการสามารถจะดำเนินการไปได้ ภายใต้งบประมาณ และ เวลาที่กำหนดไว้
Requirements elicitation process ประกอบไปด้วยกิจกรรมสำคัญ 4 อย่างได้แก่
1. การต้องจุดมุ่งหมาย (Objective setting)
วัตถุประสงค์ขององค์กร ซึ่งประกอบไปด้วย เป้าหมายหลักของธุรกิจ และการบรรยายถึงปัญหาที่ต้องการนำมาแก้ไข และข้อจำกัดของระบบเช่น งบประมาณ เวลา ควรจะถูกกำหนดออกมาในขั้นตอนนี้
2. การรู้ข้อมูลเบื้องหลังของระบบ (Background knowledge acquisition)
นี่เป็นขั้นตอนที่สำคัญมากๆ ซึ่งเป็นขั้นตอนที่ Requirements engineering จะใช้รวบรวมและเข้าใจในข้อมูลพื้นฐานต่างๆ ของระบบ และส่วนนี่ยังใช้บอกด้วยว่า ส่วนในขององค์กรที่ระบบของเราจะถูกนำไปใช้, ข้อมูล application domain ของระบบ และ ระบบที่มีอยู่แล้วในองค์กรซึ่งกำลังใช้อยู่และระบบที่จะเอาระบบที่เราพัฒนาเข้าไปแทนที่
3. การมีความรู้เกี่ยวกับภาพรวมขององค์กร (Knowledge organization)
ข้อมูลและองค์ความรู้ทั้งหมดที่ถูกเก็บมาใน 2 ส่วนที่แล้วจะถูกทำให้เป็นระบบและจัดเรียง ซึ่งได้แก่ ผู้ที่มีส่วนเกี่ยวข้องในระบบ และบทบาทของบุคคลเหล่านั้น เรียงลำดับความสำคัญเป้าหมายขององค์กร และตัดdomain knowledge ที่ไม่เกี่ยวข้องโดยตรงกับความต้องการของระบบ
4. การรวบรวมความต้องการของผู้มีส่วนได้ส่วนเสียกับระบบ (Stakeholder requirements collection)
นี่เป็นส่วนที่เรียกว่าการดึงข้อมูลออกมาจริงๆ ซึ่งรวมไปทั้งการปรึกษาผู้ที่เกี่ยวข้องในระบบเกี่ยวกับสิ่งที่บุคคลเหล่านั้นต้องการและการได้มาซึ่งความต้องการต่างๆ ที่มาจาก application domain และจากองค์กรที่ต้องการระบบของเราไปใช้งาน
ผลลัพธ์ของ requirements elicitation process
ควรจะออกมาในรูปแบบของเอกสารความต้องการต้นแบบ (draft requirements document) ที่บรรยายถึงความต้องการของระบบ ซึ่งต่อไปเอกสารนี้จะถูกนำไปวิเคราะห์ เพื่อที่จะค้นหาปัญหาและข้อขัดแย้งของความต้องการต่างๆ ของผู้ใช้ ปัญหาการขัดแย้งของความต้องการ กับปัญหาการทับซ้อนกันของความต้องการเป็นปัญหาที่ไม่สามารถหลบเลี่ยงได้ ดังนั้นจึงต้องมีขัดต้องการต่อรอง เพื่อที่จะแก้ปัญหาดังกล่าวเพิ่มเติมอีกด้วย
1.ความเข้าใจในขอบเขตของแอปพลิเคชัน (Application domain understanding)
เป็นการทำความเข้าใจเกี่ยวกับขอบเขตหัวข้อของระบบที่เราจะพัฒนา ตัวอย่างเช่นถ้าเราจะพัฒนาระบบจะทำอะไร มีขอบเขตอะไรบ้าง
2.ความเข้าใจในปัญหา (Problem understanding)
เราต้องทำความเข้าใจใน รายละเอียดของปัญหาของลูกค้าที่เราต้องใช้ระบบของเรามาจัดการนั้น ต้องเข้าใจว่าปัญหาหรืออุปสรรคใดๆ ในระบบธุรกิจหรืองานที่ต้องการนำเอาระบบคอมพิวเตอร์ไปแก้ไข คืออะไร
3.เข้าใจในธุรกิจหรือระบบที่ศึกษาอยู่ (Business understanding)
เราต้องเข้าใจว่า ระบบจะทำการปฏิสัมพันธ์ และมีผลต่อระบบธุรกิจในแต่ละส่วนอย่างไร นอกจากระบบจะสามรถช่วยเหลือเป้าหมายในทางธุรกิจของบริษัททั้งหมดได้อย่างไร
4.ความเข้าใจความต้องการ และเงื่อนไขของผู้มีส่วนได้เสียในระบบ (Understanding the needs and constraints of system stakeholders)
ในระบบมีผู้เกี่ยวข้องหลายฝ่าย แต่ละฝ่ายต้องการอะไร มีเงื่อนไขอะไร
ในขั้นตอนนี้เราจะสามารถทราบความต้องการต่างๆ โดยผู้พัฒนาระบบต้องไปปรึกษากับลูกค้า จากเอกสารของระบบ ความรู้ต่างๆ ในหัวข้อที่เราจะศึกษา การให้บริการของระบบที่เราจะพัฒนา ความต้องการของประสิทธิภาพของระบบ ข้อจำกัดทางด้านฮาร์ดแวร์ เพื่อที่จะทราบถึงแนวทางในการแก้ปัญหา
Requirements elicitation เป็นส่วนที่สำคัญมาก หากเราไม่สามารถทราบถึงความต้องการที่แท้จริงของลูกค้าแล้ว เมื่อเราพัฒนาระบบออกมา อาจทำให้ลูกค้าไม่พอใจในตัวระบบ
การรวบรวมข้อมูลความต้องการต่างๆ ระบบ ไม่ว่าจะเป็น ข้อกำหนดหรือความต้องการต่าง ๆ ของผู้ใช้งาน เอกสารข้อมูล ฮาร์ดแวร์ ข้อบังคับขององค์กร รวมทั้งกฎหมาย ในรูปแบบของ "Engineering" ซึ่งคำว่า "Engineering" ในที่นี้หมายถึง เป็นระบบ และมีการกระทำแบบซ้ำ RE มีความคล้ายคลึงหลายอย่างกับ System Analysis ในหลักการแล้ว System Analysisจะใช้สำหรับวิเคราะห์ ระบบธุรกิจซึ่งจะเจาะจงไปในทางระบบธุรกิจมากกว่าแต่ RE จะเจาะจงทั้งในระบบธุรกิจและระบบคอมพิวเตอร์ด้วย
1 ใช้ชีวิตรอบแบ่งวางแผนการจัดการที่เข้มงวด
ถูกค้นพบโดยสถิติในโครงการซอฟต์แวร์สำเร็จประมาณครึ่งหนึ่งเกิดจากการวางแผนไม่ดีเกิดการจัดตั้งแผนเสียงสามารถเห็นเป็นหลักการพื้นฐานแรกคือการเรียนรู้บทเรียนของรุ่นก่อนของเรานำมา ในการพัฒนาซอฟต์แวร์และการบำรุงรักษาวงจรชีวิตยาวต้องดำเนินการทำงานของคุณสมบัติต่างๆ นี้หมายถึงหลักการพื้นฐานที่ควรวงจรชีวิตของซอฟต์แวร์แบ่งออกเป็นหลายขั้นตอนและสอดคล้องกันดีพัฒนาแผนการทำงานได้และอย่างเคร่งครัดตามแผนพัฒนาซอฟต์แวร์ที่เหมาะสมและบำรุงรักษาประสิทธิภาพการจัดการ Boehm เชื่อว่าซอฟต์แวร์วงจรชีวิตทั้งหมดจะต้องพัฒนาและเข้มงวดหกแผนการซึ่งร่างแผนโครงการ, เหตุการณ์สำคัญแผนการ, แผนควบคุมโครงการแผนควบคุมสินค้าแผนการตรวจสอบการดำเนินงานและวางแผนการบำรุงรักษา ระดับต่างๆของการจัดการจะต้องเคร่งครัดตามแผนการเล่นส่วนหนึ่งของเขาในการจัดการการพัฒนาซอฟต์แวร์และงานบำรุงรักษาจะต้องไม่ได้รับผลกระทบจากลูกค้าหรือเจ้าหน้าที่ระดับสูงของการเดินทางไม่ได้รับอนุญาตจากตาราง
2 ยืนยันในระยะการประเมิน
มาแล้วรู้จักการประกันคุณภาพซอฟต์แวร์ไม่สามารถรอจนกว่าขั้นตอนการเขียนโปรแกรมเพิ่มเติม กล่าวว่าอย่างน้อยสองสาเหตุ : ก่อนที่ส่วนใหญ่ข้อผิดพลาดเกิดจากการเข้ารหัสเช่น Boehm และอื่น ๆ ตามสถิติข้อผิดพลาดการออกแบบคิด 63% ของความผิดพลาดซอฟต์แวร์เข้ารหัสเพียง 37%; ข้อผิดพลาดที่สองพบ คืนมากขึ้นด้วยการแก้ไขค่าใช้จ่ายสูง ดังนั้นในขั้นตอนการตรวจสอบทุกอย่างเคร่งครัดเพื่อตรวจหาซอฟต์แวร์ที่พัฒนาผิดพลาดการเป็นหลักการสำคัญที่ต้องติดตาม
3 การดำเนินการควบคุมสินค้าที่เข้มงวด
ในกระบวนการพัฒนาซอฟต์แวร์ไม่ควรยุ่งเกี่ยวกับความต้องการความต้องการเปลี่ยนแปลงต้องมักจะต้องจ่ายราคาที่สูงขึ้น แต่ในกระบวนการการพัฒนาซอฟต์แวร์จำเป็นต้องเปลี่ยนแปลงแน่นอนเนื่องจากมีการเปลี่ยนแปลงในสภาพแวดล้อมภายนอกเปลี่ยนแปลงที่สอดคล้องกันในผู้ใช้ต้องการ ต้องมีวัตถุประสงค์แน่นอนไม่ยากต่อความต้องการเปลี่ยนแปลงความต้องการของลูกค้า แต่ต้องพึ่งพาวิทยาศาสตร์และเทคโนโลยีการควบคุมสินค้าให้สอดคล้องกับความต้องการนี้ กล่าวคือเมื่อการเปลี่ยนแปลงของความต้องการเพื่อรักษาความสอดคล้องของส่วนประกอบในการกำหนดค่าต่างๆของผลิตภัณฑ์ที่ต้องควบคุมอย่างเคร่งครัดส่วนใหญ่การดำเนินการจัดการการตั้งค่าพื้นฐาน มาตรฐานที่เรียกว่ารู้จักกันเป็นค่าพื้นฐานซึ่งมีผลหลังจากระยะการประเมินองค์ประกอบการกำหนดค่าซอฟต์แวร์ (ผลิตในขั้นตอนต่างๆของเอกสารหรือโปรแกรม code) การจัดการการตั้งค่า Baseline เรียกว่าการควบคุมการเปลี่ยนแปลง : แก้ไขซอฟต์แวร์แนะนำ ๆ โดยเฉพาะที่เกี่ยวข้องกับการเปลี่ยนแปลงที่เสนอการกำหนดค่าพื้นฐานที่จะต้องประเมินตามกฎเข้มงวด, ได้รับการอนุมัติก่อนดำเนินการเปลี่ยนแปลง ไม่แน่นอนที่ต้องการแก้ไขซอฟต์แวร์ (ยังอยู่ในกระบวนการพัฒนาซอฟต์แวร์รวมทั้ง), ฟรีการเปลี่ยนแปลงใน
4 โดยใช้เทคนิคการเขียนโปรแกรมสมัยใหม่
เสนอแนวคิดของวิศวกรรมซอฟต์แวร์ตั้งแต่ต้นคนได้ใช้ในการศึกษาพลังงานหลักของเทคนิคการเขียนโปรแกรมใหม่ โครงสร้างเสนอเทคนิคการเขียนโปรแกรมปลาย 60 ของกลายเป็นคนส่วนใหญ่ยอมรับในการเขียนโปรแกรมเทคนิคขั้นสูง หลังจากการพัฒนาเพิ่มเติมความหลากหลายของการวิเคราะห์โครงสร้าง (SA) และการออกแบบโครงสร้าง (SD) เทคโนโลยี ปฏิบัติแสดงให้เห็นว่าการใช้เทคโนโลยีขั้นสูงสามารถปรับปรุงประสิทธิภาพของการพัฒนาซอฟต์แวร์ แต่ยังปรับปรุงประสิทธิภาพของซอฟต์แวร์การบำรุงรักษา
5 ผลควรตรวจสอบอย่างชัดเจน
ผลิตภัณฑ์ซอฟแวร์ต่างจากผลิตภัณฑ์ทางกายภาพก็ไม่สามารถดูสินค้าตรรกะ Zheng สัมผัส นักพัฒนาซอฟแวร์ (หรือการพัฒนาทีมงาน) สามารถดูความคืบหน้าของงานและยากจนยากที่จะแม่นยำในการวัดที่ให้ซอฟต์แวร์ผลิตภัณฑ์กว่ากระบวนการพัฒนากระบวนการพัฒนาผลิตภัณฑ์ยากในการประเมินผลและการจัดการ เพื่อปรับปรุงการแสดงผลของการพัฒนาซอฟต์แวร์การจัดการที่ดีขึ้นโครงการพัฒนาซอฟต์แวร์ควรเป็นไปตามวัตถุประสงค์และกรอกระยะเวลารวมบทบัญญัติของความรับผิดชอบขององค์กรพัฒนาและมาตรฐานสินค้าซึ่งจะทำให้ผลที่ได้จะชัดเจน Shencha
6 ทีมพัฒนาของเจ้าหน้าที่มีน้อย
หลักการพื้นฐานนี้หมายความว่าซอฟต์แวร์การพัฒนาทีมงานควรจะมีคุณภาพดี แต่จำนวนไม่มากเกินไป ทีมพัฒนาและมีผลต่อคุณภาพและปริมาณของผลิตภัณฑ์ซอฟต์แวร์ที่มีคุณภาพและประสิทธิภาพการพัฒนาปัจจัยสำคัญ การพัฒนาบุคลากรที่มีคุณภาพสูงที่มีประสิทธิภาพมากกว่าที่มีคุณภาพต่ำของประสิทธิภาพการพัฒนาบุคลากรอาจมีหลายครั้งครั้งสิบหลายสูงและซอฟต์แวร์ที่มีคุณภาพสูงที่พัฒนาโดยทีมงานของข้อผิดพลาดน้อยกว่าที่มีคุณภาพต่ำของซอฟต์แวร์ที่พัฒนาโดยทีมงานของข้อผิดพลาด นอกจากนี้กับทีมพัฒนาและเพิ่มจำนวนเป็นผลจากการแลกเปลี่ยนเพื่อหารือเกี่ยวกับปัญหาของค่าใช้จ่ายในการสื่อสารที่ยังเพิ่มขึ้นอย่างรวดเร็ว เมื่อทีมพัฒนาและจำนวน N, เส้นทางการสื่อสารเป็นไปได้ด้วย N (N? / บทความ FONT 1) / 2 จะเห็นเป็นเพิ่ม N จำนวนค่าใช้จ่ายในการสื่อสารจะเพิ่มขึ้นอย่างรวดเร็ว ดังนั้นทีมพัฒนาประกอบด้วยวิศวกรรมน้อย แต่เป็นหลักการพื้นฐานของซอฟต์แวร์
7 ต่อการรับรู้ต้องปรับปรุงการปฏิบัติงานวิศวกรรมซอฟต์แวร์
ตาม 6 หลักการพื้นฐานเราสามารถตามหลักการพื้นฐานของวิศวกรรมซอฟต์แวร์สมัยใหม่วิศวกรรมซอฟต์แวร์เพื่อให้บรรลุการผลิต แต่เหล่านี้หกหลักไม่สามารถรับประกันได้ว่ากระบวนการพัฒนาซอฟต์แวร์และการบำรุงรักษาให้ทันกับความก้าวหน้าเพื่อให้ทันกับเทคโนโลยี ความคืบหน้า l ดังนั้น Boehm ควรเสนอต่อการปรับปรุงการวิศวกรรมซอฟต์แวร์จำเป็นต้องได้รับการยอมรับสำหรับวิศวกรรมซอฟต์แวร์เป็นหลักการพื้นฐานของข้อ VII ตามหลักการนี้ไม่ควรใช้ความคิดริเริ่มเพื่อนำเทคโนโลยีซอฟต์แวร์ใหม่ แต่ยังให้ความสนใจอย่างต่อเนื่องรวมถึงประสบการณ์เช่นความคืบหน้าการรวบรวมข้อมูลและทรัพยากรที่ต้องใช้พิมพ์ผิดพลาดและรายงานปัญหาในการเก็บข้อมูลและอื่นๆ ข้อมูลเหล่านี้ไม่เพียง แต่สามารถใช้ในการประเมินผลกระทบของเทคโนโลยีซอฟต์แวร์ใหม่ แต่ยังสามารถใช้เพื่อระบุต้องเน้นการพัฒนาเครื่องมือซอฟต์แวร์และเทคโนโลยีควรจะให้ความสำคัญ,
1.การจัดการโครงการ
2.วิธีปฏิบัติในการจัดการข้อกำหนด
3.การตรวจสอบข้อกำหนด
4.การกำหนดรายละเอียดของข้อกำหนด
5.การหาข้อกำหนด
6.การจัดการข้อกำหนด
7.การพัฒนาข้อกำหนด
8.ลักษณะเฉพาะของข้อความของข้อกำหนด
9.ความเสี่ยงจากกระบวนการของข้อกำหนดที่ไม่ดีพอ
10.ระดับของข้อกำหนด
มี 3 ระดับคือ
1. ข้อกำหนดทางธุรกิจ หมายถึง วัตถุประสงค์ระดับสูงของหน่วยงานหรือลูกค้าที่ขอให้มีอยู่ในระบบหรือซอฟต์แวร์ ซึ่งปรากฎในเอกสารที่อธิบายภาพรวมและขอบเขตของโครงการ
2. ข้อกำหนดของผู้ใช้ หมายถึง งานที่ผู้ใช้สามารถทำให้สำเร็จได้ด้วยซอฟต์แวร์ ซึ่งกล่าวถึงในกรณีที่ต้องนำมาใช้งาน หรือการอธิบายถึงสถานการณ์สมมติ (scenario)
3. ข้อกำหนดด้านฟังก์ชัน หมายถึง การทำงานของซอฟต์แวร์ที่ผู้พัฒนาสร้างไว้ในซอฟต์แวร์ เพื่อให้ผู้ใช้ทำงานได้สำเร็จ
x.25 เป็นโปรโตคอลมาตรฐานของเครือข่ายแบบเก่า ได้รับการออกแบบโดย CCITT ประมาณปี ค.ศ. 1970 เพื่อใช้เป็นส่วนตัวติดต่อระหว่างระบบเครือข่ายสาธารณะแบบแพ็กเก็ตสวิตช์ (Packet Switching) กับผู้ใช้ระบบ X.25 เป็นการสื่อสารแบบต่อเนื่อง (Connection-oriented) ที่สนับสนุนการเชื่อมต่อวงจรสื่อสารแบบ Switched Virtual Circuit(SVC) และ Permanent Virtual Circuit (PVC)
Frame Relay เฟรมรีเลย์เป็นเทคโนโลยีที่พัฒนามาต่อจาก x.25 อีกทีหนึ่งในการส่งข้อมูล เฟรมรีเลย์จะมีการตรวจเช็กความถูกต้องของข้อมูลที่จุดปลายทาง ทำงานแบบ Packet Switching
ATM (Asynchronous Transfer Mode) เป็นระบบเครือข่ายความเร็วสูง ปัจจุบันระบบองค์กรใหญ่ๆ นิยมใช้งานอย่างแพร่หลายในวงอุตสาหกรรมการสื่อสาร โดยระบบ ATM จะมีการส่งข้อมูลจำนวนน้อยๆ ที่มีขนาดคงที่เรียกว่า "เซลล์" (Cell)
มาตรฐานเครือข่าย LAN ที่นิยมนำมาใช้กันทั่วไป มี 3 แบบ คือ
Ethernet พัฒนาขึ้นโดยบริษัท Xerox เป็นมาตรฐานของระบบเครือข่าย LAN ที่ได้รับความนิยมมากที่สุดในปัจจุบัน ช่วงหลังได้รับการดูแลและกำหนดฐานโดยสถาบันวิศวกรไฟฟ้าและอิเล็กทรอนิกส์ IEEE (Institute of Electrical and Electronics Engineers) โดยที่มาตรฐาน Ethernet ที่นิยมในระบบเครือข่าย LAN จะใช้มาตรฐาน IEEE 802.3 เช่น Ethernet (10 Mbps),Fast Ethernet (100 Mbps),Gigabit Ethernet (1000 Mbps) โดยที่ Ethernet จะใช้เทคนิคการส่งข้อมูลแบบ CSMA/CD กล่าวคือถ้าเกิดการส่งข้อมูลพร้อมกันและสัญญาณชนกัน จะต้องมีการส่งข้อมูลใหม่
Token-Ring พัฒนาขึ้นโดยบริษัท IBM จะใช้ Access Method แบบ Token Passing ในการเชื่อมต่อสามารถใช้ได้ทั้งสาย Coaxial,UTP,STP หรือสายเส้นใยแก้วนำแสง (Fiber optic) ระบบเครือข่ายแบบนี้มีความคงทนต่อควาผิดพลาดสูง (Fault-tolerant) ความเร็วในการรับส่งข้อมูลจะอยู่ที่ 4-16 Mbps
FDDI (Fiber Distributed Data Interface) เป็นมาตรฐานเครือข่ายความเร็วสูงที่กำหนดขึ้นโดย ANSI และหน่วยงานมาตรฐานสากล (OSI) ทำงานอยู่ในชั้น Physical ส่วนมากนำไปใช้เชื่อมต่อเป็น Backbone (เป็นสายสัญญาณหลักเชื่อมต่อระหว่างเครือข่ายLANเข้าด้วยกัน) ใช้ Access Method แบบ Token-passing และใช้ Topology แบบวงแหวนคู่ (Dual Ring) ซึ่งช่วยทำให้ทนทานต่อข้อบกพร่อง (Fault-tolerant) ของระบบเครือ่ขายได้ดีขึ้น ทำงานอยู่ที่ความเร็ว 100 Mbps
การเชื่อมต่อแบบ Bus เป็นการเชื่อมต่อแบบเส้นทางเดียว มีลักษณะคล้ายท่อน้ำประปา ใช้สาย coaxial เพียงเส้นเดียวเป็นแกนหลักในการเชื่อมต่อ ด้านหัวและท้ายจะมี Terminator เป็นตัวปิด ระบบแบบนี้มีข้อเสียตรงที่หากจุดใดจุดหนึ่งขาดระบบโดยรวมจะทำงานไม่ได้ ระยะทางในการต่อจากสายเมนหลักไปยังเครื่องมีสองระบบคือ 200 เมตร (10Base2) และ 500 เมตร (10Base5) ปัจจุบันการเชื่อมต่อแบบ Bus ไม่นิยมใช้กันแล้ว เพราะความเร็วของการส่งจะอยู่ที่ 10 Mbps
การเชื่อมต่อแบบ Star การเชื่อมต่อจะมีอุปกรณ์ Hub/Switch เชื่อมต่ออยู่ตรงกลาง เครื่องคอมพิวเตอร์เชื่อมต่อกันโดยใช้สาย UTP/STP เป็นรูปแบบการเชื่อมต่อที่ได้รับความนิยมมากที่สุดในปัจจุบัน โดยการต่อสาย ระยะทางจากคอมพิวเตอร์ไปยัง Hub/Switch ยาวสุดประมาณ 100เมตร (10BaseT/100BaseT) กรณียาวเกิน 100 เมตร ก็สามารถใช้ Hub หรือ Switch เพื่อเพิ่มระยะทางได้
การเชื่อมต่อแบบ Ring เป็นการเชื่อมต่อคอมพิวเตอร์เข้าด้วยกันเป็นรูปวงกลม มีลักษณะเหมือนวงแหวน คิดค้นโดยบริษัท IBM เป็นระบบที่เสถียรภาพมากที่สุด ไม่ค่อยได้รับความนิยม เนื่องจากค่าติดตั้งค่อนข้างสูง
เรียกกันในนามไอพีปลอม หรือ ไอพีภายใน โดยไอพีนี้จะถูกนำมาใช้งานสำหรับองค์กรที่ไม่ได้เชื่อมต่ออินเตอร์เน็ต ไอพีปลอมนั้นในปัจจุบันถูกนำมาใช้งานกันอย่างกว้างขวาง ส่วนมากถูกนำมาใช้ในการจ่ายเครื่องลูกข่ายในองค์กร เช่น
ร้านอินเทอร์เน็ตคาเฟ่
ทำเป็นระบบ NAT ในการจ่ายไอพีให้เครื่องลูกข่ายในองค์กร
ใช้ทำระบบ Internetใช้งานในองค์กร
Class | Range of IP | ||
Class A | 10.0.0.0 | ถึง | 10.255.255.255 |
Class B | 172.16.0.0 | ถึง | 172.31.255.255 |
Class C | 192.168.0.0 | ถึง | 192.168.255.255 |
การแบ่ง IP Address ออกเป็นหลายระดับ ความจริงก็แบ่งตามความใหญ่ ของเครือข่ายนั่นเอง
Network Class | Subnet mask | Network Addresses |
A | 255.0.0.0 | 0.0.0.0-127.255.255.255 |
B | 255.255.0.0 | 128.0.0.0-191.255.255.255 |
C | 255.255.255.0 | 192.0.0.0-223.255.255.255 |
Multicast | 240.0.0.0 | 224.0.0.0-239.255.255.255 |
Class A Network
ระบบเครือข่ายคลาส A มีแอดเดรสเริ่มต้นตั้งแต่ 0 จนถึง 127 (Network Portion) ตัวเลขที่เหลืออีกสามส่วน เป็น host protion จะเห็นว่าเป็นระบบเครือข่ายที่ใหญ่มาก สามารถมีอุปกรณ์ (router, host ฯ) ต่างๆ ไม่ซ้ำกันได้ถึง 16 ล้านตัว ระบบเครือข่ายคลาส A ได้ถูกกำหนดให้กับบริษัทต่าง จนหมดไปนานแล้ว
Class B Network
มีแอดเดรสเริ่มตั้งแต่ 128 จนถึง 192 มีระบบเครือข่ายคลาส B อยู่ 16,000 เครือข่าย ในแต่ละเครือข่าย จะมีแอดเดรสที่ไม่ซ้ำกันอยู่ 64,000 แอดเดรส และก็ถูกกำหนดให้กับองค์กร หรือบริษัทใหญ่ๆ หมดแล้วเช่นกัน เหตุที่เครือข่ายนี้ไม่ใหญ่เท่า เครือข่ายคลาส A เนื่องจากถูกกำหนดโดย Subnet mask
Class C Network
มีแอดเดรสเริ่มตั้งแต่ 192 จนถึง 223 ซึ่งมีอยู่ประมาณ 2 ล้านเครือข่าย แต่ละเครือข่ายมีอุปกรณ์ได้สูงสุด 254 ตัว
Multicast
หรืออาจเรียกได้ว่าเป็น เครือข่ายคลาส D มีแอดเดรสเริ่มต้นตั้งแต่ 224 จนถึง 239 สำหรับใช้งานในลักษณะเหมือนกับ วิทยุหรือโทรทัศน์ คือส่งออกไปอย่างเดียว ใครจะรับก็ไปดักรับเอา ส่วนแอดเดรส 240 ถึง 247 เป็นของระบบเครือข่ายคลาส E ซึ่งในส่วนนี้เก็บไว้ใช้ในอนาคต
Subnet
เป็นส่วนหนึ่งของระบบเครือข่าย ซึ่งเหมือนกับแยกตัวออกมาต่างหาก แต่จะมีจุดเชื่อมต่อเพียงจุดเดียวโดยผ่าน router สิ่งที่ช่วยให้เราแยกตัวออกมาจากเครือข่าย คือ subnet mask แต่คอมพิวเตอร์ใน subnet mask เดียวกันสามารถติดต่อกันได้โดยตรง ตัวอย่าง mask ของเครือข่ายคลาส C คือ 255.255.255.0 ขอยกตัวอย่างให้ดูเช่น IP address ของคอมพิวเตอร์เครื่องหนึ่งเป็น 192.168.1.20 คอมพิวเตอร์เครื่องนี้ก็จะสามารถติดต่อกับ คอมพิวเตอร์ที่มี IP ตั้งแต่ 192.168.1.0 - 192.168.1.255 จะไม่สามารถติดต่อกับเครื่องคอมพิวเตอร์ 192.168.2.1 ได้เลยเพราะอยู่คนละ subnet
โดยแต่ละ Layer ของ OSI Model จะมีหน้าที่ต่างกันดังนี้
Physical Layer
ชั้น Physical เป็นการอธิบายคุณสมบัติทางกายภาพ เช่น คุณสมบัติทางไฟฟ้า และกลไกต่างๆ ของวัสุที่ใช้เป็นสื่อกลาง ตลอดจนสัญญาณที่ใช้ในการส่งข้อมูล คุณสมบัติที่กำหนดไว้ในชั้นนี้ประกอบด้วยคุณลักษณะทางกายภาพของสาย, อุปกรณ์เชื่อมต่อ (Connector), ระดับความตางศักย์ของไฟฟ้า (Voltage) และอื่นๆ เช่น อธิบายถึงคุณสมบัติของสาย Unshield Twisted Pair (UTP)
Datalink Layer
ชั้น Datalink เป็นชั้นที่อธิบายถึงการส่งข้อมูลไปบนสื่อกลาง ชั้นนี้ยังได้ถูกแบ่งออกเป็นชั้นย่อย (SubLayer) คือ Logical Link Control (LLC) และ Media Access Control (MAC) การแบ่งแยกเช่นนี้จะทำให้ชั้น LLC ชั้นเดียวสามารถจะใช้ชั้น MAC ที่แตกต่างกันออกไปได้หลายชั้น ชั้น MAC นั้นเป็นการดำเนินการเกี่ยวกับแอดเดรสทางกายภาพอย่างที่ใช้ในมาตรฐานอีเทอร์เน็ตและโทเคนริง แอดเดรสทางกายภาพนี้จะถูกฝังมาในการ์ดเครือข่ายโดยบริษัทผู้ผลิตการ์ดนั้น แอดเดรสทางกายภาพนั้นเป็นคนละอย่างกับแอดเดรสทางตรรกะ เช่น IP Address ที่จะถูกใช้งานในชั้น Network เพื่อความชัดเจนครบถ้วนสมบูรณ์ของการใช้ชั้น Data-Link นี้
Network Layer
ในขณะที่ชั้น Data-Link ให้ความสนใจกับแอดเดรสทางกายภาพ แต่การทำงานในชั้น Network จะให้ความสนใจกับแอดเดรสทางตรรกะ การทำงานในชั้นนี้จะเป็นการเชื่อมต่อและการเลือกเส้นทางนำพาข้อมูลระหวางเครื่องสองเครื่องในเครือข่ายชั้น Network ยังให้บริการเชื่อมต่อในแบบ "Connection Oriented" อย่างเช่น X.25 หรือบริการแบบ "Connectionless" เช่น Internet Protocol ซึ่งใช้งานโดยชั้น Transport ตัวอย่างของบริการหลักที่ชั้น Network มีให้คือ การเลือกส้นทางนำพาข้อมูลไปยังปลายทางที่เรียกว่า Routing
ตัวอย่างของโปรโตคอลในชั้นนี้ประกอบด้วย Internet Protocol (IP) และ Internet Control Message Protocol (ICMP)
Transport Layer
ในชั้นนี้มีบางโปรโตคอลจะให้บริการที่ค่อนข้างคล้ายกับที่มีในชั้น Network โดยมีบริการด้านคุณภาพที่ทำให้เกิดความน่าเชื่อถือ แต่ในบางโปรโตคอลที่ไม่มีการดูแลเรื่องคุณภาพดังกล่าวจะอาศัยการทำงานในชั้น Transport นี้เพื่อเข้ามาช่วยดูแลเรื่องคุณภาพแทน เหตุผลที่สนับสนุนการใช้งานชั้นนี้ก็คือ ในบางสถานการณ์ของชั้นในระดับล่างทั้งสาม (คือชั้น Physical, Data-Link และ Network) ดำเนินการโดยผู้ให้บริการโทรคมนาคม การจะเพิ่มความมั่นใจในคุณภาพให้กับผู้ใช้บริการก็ด้วยการใช้ชั้น Transport นี้
"Transmission Control Protocol (TCP) เป็นโปรโตคอลในชั้น Transport ที่มีการใช้งานกันมากที่สุด"
Session Layer
ชั้น Session ทำหน้าที่สร้างการเชื่อมต่อ, การจัดการระหว่างการเชื่อมต่อ และการตัดการเชื่อมต่อคำว่า "เซสชัน" (Session) นั้นหมายถึงการเชื่อมต่อกันในเชิงตรรกะ (Logic) ระหว่างปลายทางทั้งสองด้าน (เครื่อง 2 เครื่อง) ชั้นนี้อาจไม่จำเป็นต้องถูกใช้งานเสมอไป อย่างเช่นถ้าการสื่อสารนั้นเป็นไปในแบบ "Connectionless" ที่ไม่จำเป็นต้องเชื่อมต่อ เป็นต้น ระหว่างการสื่อสารในแบบ "Connection-less" ทุกๆ แพ็กเก็ต (Packet) ของข้อมูลจะมีข้อมูลเกี่ยวกับเครื่องปลายทางที่เป็นผู้รับติดอยู่อย่างสมบูรณ์ในลักษณะของจดหมายที่มีการจ่าหน้าซองอย่างถูกต้องครบถ้วน ส่วนการสื่อสารในแบบ "Connection Oriented" จะต้องมีการดำเนินการบางอย่างเพื่อให้เกิดการเชื่อมต่อ หรือเกิดเป็นวงจรในเชิงตรรกะขึ้นมาก่อนที่การรับ/ส่งข้อมูลจะเริ่มต้นขึ้น แล้วเมื่อการรับ/ส่งข้อมูลดำเนินไปจนเสร็จสิ้นก็ต้องมีการดำเนินการบางอย่างเพื่อที่จะตัดการเชื่อมต่อลง ตัวอย่างของการเชื่อมต่อแบบนี้ได้แก่การใช้โทรศัพท์ที่ต้องมีการกดหมายเลขปลายทาง จากนั้นก็ต้องมีการดำเนินการบางอย่างของระบบจนกระทั่งเครื่องปลายทางมีเสียงดังขึ้น การสื่อสารจะเริ่มขึ้นจริงเมื่อมีการทักทายกันของคู่สนทนา จากนั้นเมื่อคู่สนทนาฝ่ายใดฝ่ายหนึ่งวางหูก็ต้องมีการดำเนินการบางอย่างที่จะตัดการเชื่อมต่อลงชั้น Session นี้มีระบบการติดตามด้วยว่าฝั่งใดที่ส่งข้อมูลซึ่งเรียกว่า "Dialog Management"
Simple Mail Transport Protocol (SMTP), File Transfer Protocol (FTP) และ Telnet เป็นตัวอย่างของโปรโตคอลที่นิยมใช้ และมีการทำงานครอบคลุมในชั้น Session, Presentation และ Application
Presentation Layer
ชั้น Presentation ให้บริการทำการตกลงกันระหว่างสองโปรโตคอลถึงไวยากรณ์ (Syntax) ที่จะใช้ในการรับ/ส่งข้อมูล เนื่องจากว่าไม่มีการรับรองถึงไวยากรณ์ที่จะใช้ร่วมกัน การทำงานในชั้นนี้จึงมีบริการในการแปลข้อมูลตามที่ได้รับการร้องขอด้วย
Application Layer
ชั้น Application เป็นชั้นบนสุดของแบบจำลอง ISO/OSI เป็นชั้นที่ใช้บริการของชั้น Presentation (และชั้นอื่นๆ ในทางอ้อมด้วย) เพื่อประยุกต์ใช้งานต่างๆ เช่น การทำ E-mail Exchange (การรับ/ส่งอีเมล์), การโอนย้ายไฟล์ หรือการประยุกต์ใช้งานทางด้านเครือข่ายอื่นๆ
Layer | Functionality | Devices | Protocols/Services |
7 | Application Layer | Gateway | HTTP,HTTPS,Telnet,SMTP,POP3,IMAP,FTP,IRC,SSH,UUCP |
6 | Presentation Layer | ASCII,EBCDIC,JPEG | |
5 | Session Layer | NFS, Named Pipes | |
4 | Transport Layer | TCP,UDP,SPX,SCTP | |
3 | Router, Switch Layer3 | IPv4,IPv6,IPX,ICMP,IGMP,ARP,IPSec | |
2 | Data-Link Layer | Bridge, Switch | Ethernet,WiFi,HDLC,FDDI,Frame relay,PPP,ATM |
1 | Physical Layer | Hub,Repeater | RS-232,EIA,TIA-232,V.35 |
OSI Model
OSI Model เป็น model มาตรฐานในการสื่อสารซึ่งมีวัตถุประสงค์ ใช้สำหรับการสื่อสารระหว่างระบบ 2 ระบบ ระบบจะเปิดการติดต่อสื่อสารในเค้าโครงสำหรับออกแบบ
ระบบเครือข่าย จะอนุญาตให้สื่อสารข้ามทุกรูปแบบของระบบคอมพิวเตอร์แยกเป็น 7 ชั้นแต่เกี่ยวเนื่องกันและเป็นรูปแบบมาตรฐาน ISO
OSI Model ประกอบด้วย 7 Layer
