ระบบ คือ การที่นำเอาองค์ประกอบย่อย ( Component ) หลายๆองค์ประกอบย่อยมาประกอบกัน เพื่อให้มันทำงานร่วมกันออกมาได้บรรลุวัตถุประสงค์ขององค์กร และองค์ประกอบที่ว่ามักจะเป็น Software การทำงานขององค์ประกอบย่อยควรทำงานเป็นเอกเทศของตัวเอง ไม่ต้องไปพึ่งองค์ประกอบย่อยส่วนอื่น

Property – เป็นคุณสมบัติของระบบซึ่งถ้าเราจะวัดวัดคุณสมบัติของระบบ เราจะวัดจากคุณสมบัติขององค์ประกอบย่อยแต่ละตัวแล้วนำมารวมกัน แล้วตีความว่าเป็นคุณสมบัติของระบบ สิ่งที่เรามักจะวัดได้แก่
1. น้ำหนักความสำคัญของระบบ – จำเป็นแค่ไหน ถ้ามีความผิดพลาดจะเกิดอะไรขึ้น (มักจะวัดก่อนการสร้างระบบ)
2. ความน่าเชื่อถือของระบบ – Hang บ่อยแค่ไหน , ทำงานผิพลาดบ่อยแค่ไหน
3. ความสามารถในการใช้งานได้จริงมากน้อยแค่ไหน (มักจะวัดหลังจากสร้างเสร็จรอบแรก)

คุณสมบัติของระบบ
แบ่งออกเป็น 2 ส่วนใหญ่ๆ
1. Functional Property – เป็นคุณสมบัติที่เกี่ยวข้องกับการทำงานโดยตรง เช่น software ต้องสามารถรับข้อมูลลูกค้าทางคีย์บอร์ดได้
2. Non-Funtional Property – เป็นคุณสมบัติที่ไม่เกี่ยวข้องกับการทำงาน เช่น ความน่าเชื่อถือ , ความปลอดภัย , ขนาดของจอมอนิเตอร์ที่ใช้แสดงผล

ประเภทของ Component
1. Sensor – เป็น component ที่ทำหน้าที่รับข้อมูลจากภายนอกระบบ ( environment ) เข้าสู่ระบบ เช่น ระบบกันขโมยsensor จะคอยตรวจสอบการเปิดประตูรถ
2. Actualator – ทำหน้าที่เปลี่ยนสภาพแวดล้อมที่มันอยู่ เช่น ระบบกันขโมยจะส่งเสียงเมื่อมีการเปิดประตู
3. Computation – component ที่ต้องมีส่วนการคำนวณ
4. Communication – ใช้ในการติดต่อสื่อสาร เช่น การติดต่อวิทยุ , โทรศัพท์
5. Coordination – component ที่ทำให้โปรแกรมส่วนอื่นทำงานได้ ( Main program )
6. Interface – เป็น component ที่ติดต่อกับผู้ใช้ทั้งการนำเสนอข้อมูล และรับข้อมูลจากผู้ใช้ ต่างกับ sensor เพราะ sensor จะรับข้อมูลจากสภาพแวดล้อมของระบบ

ตย. ระบบเตือนภัย <Intruder Alarm System>

อธิบาย : ระบบมีระบบย่อยทำงานอยู่หลายระบบย่อย โดยในตัวอย่างประกอบด้วยระบบย่อย 6 ระบบ โดยที่

- Movement Sensor กับ Doors Sensor ทำหน้าที่เป็น Sensor Component คือ รับข้อมูลจากสภาพแวดล้อม เข้าสู่ระบบ กล่าวคือ มีการเคลื่อนไหว , ประตูเปิด เพราะฉะนั้นจึงเป็น input ของระบบ
- จากนั้นส่งข้อมูลให้กับส่วน Alarm Controller ซึ่งทำหน้าที่เป็น Co-ordinator ประสานงานอื่นให้ทำงานต่อไป โดยที่อาจจะไปสั่งให้ Siren ทำงานส่งเสียงร้องออกมา โดยที่ Siren ก็ทำหน้าที่เป็น Actuator เพราะฉะนั้นจึงเป็น Output หนึ่งของระบบนั่นเอง
- หรือ Alarm Controller อาจจะไปสั่งให้ Voice Synthesizer ทำงานซึ่ง Voice Synthesizer ก็คือระบบย่อยที่สร้างสังเคราะห์เสียงขึ้นมา เช่นเป็นเสียงพูดเตือนมีผู้บุกรุกเข้ามา เป็นต้น ในที่นี้ Voice Synthesizer ทำหน้าที่เป็น Interface ติดต่อกับผู้ใช้
- หรือ Alarm Controller อาจจะสั่งให้ Telephone Caller หมุนโทรศัพท์ก็ได้ ซึ่ง Telephone Caller ทำหน้าที่เป็น Communication นั่นเอง

จากตัวอย่างข้างต้นเป็นตัวอย่างของคำว่า “ System ” ซึ่ง System ประกอบไปด้วย Sub-system ย่อยๆที่แตกต่างกันแต่ทำงานร่วมกัน โดยหน้าที่หรือประเภทของ Component มี 6 ประเภทที่กล่าวมาข้างต้น

ตย. ระบบการควบคุมการจราจรทางอากาศ ( ระบบ ATC [ Air Traffic Controller ] )

อธิบาย :
- ส่วนแรกประกอบด้วย Radar กับ Transponder จะรับข้อมูลจากสภาพแวดล้อม ทั้ง 2 ตัวทำหน้าที่เป็น Sensor รับข้อมูลเข้ามาสู่ Process คือส่วนของ Position Processor และ Backup position ซึ่งทำหน้าที่เป็น Computation โดยอาจจะมีการคำนวณความสูงการบิน เป็นต้น โดยที่ส่วนของ Process ตรงนี้ยังได้รับข้อมูลจาก Aircraft simulation system เข้ามาช่วยในการคำนวณต่างๆด้วย เมื่อได้ข้อมูลมากพอแล้ว ข้อมูลทั้งหมดก็จะถูกส่งไปยังส่วน Controller Information System โดยตรงนี้จะมีข้อมูลต่างๆเยอะมาก เพราะมันได้รับข้อมูลมาจากหลายแหล่งกล่าวคือ Weather map system , Fight plan database เป็นต้น นอกจากนั้น ข้อมูลตรงส่วนของ Information System ตรงนี้ยังถูกส่งไปคำนวณบัญชีจ่างๆที่ Accounting System ด้วย
- มีการสื่อสารมาโดยตรงจากเครื่องบินทางวิทยุ เพราะฉะนั้น Aircraft communication และ Telephone system นี้จะเป็น Communication ไม่ใช่ Sensor เพราะ Sensor ไม่ได้สื่อสาร แต่มันเป็นการรับรู้ว่าสภาพแวดล้อมมีการเปลี่ยนแปลงอะไรหรือไม่เท่านั้นเอง ส่วน Fight plan database จะทำหน้าที่เป็น Co-ordinator เพราะว่าเครื่องบินจะต้องมีการส่งแผนการบินก่อนล่วงหน้า เพราะฉะนั้น ตรงนี้มีข้อมูลอยู่แล้ว ทาง Controller information system ก็รับข้อมูลจาก Fight plan ด้วย และก็ยังมีส่วนอื่นๆเช่น Data communication system รับข้อมูลจากตรงนี้ไปทำงานอย่างอื่นอีก

เพราะฉะนั้นจากตัวอย่างนี้ทำให้เราเห็นภาพของระบบ 1 ระบบที่ประกอบด้วยระบบย่อยหลายๆตัวมาทำงานร่วมกันโดยทำหน้าที่แตกต่างกัน ดังนั้นเวลาที่เราจะออกแบบระบบขึ้นมา 1 ระบบเราต้องคำนึงด้วยว่าระบบของเราจะแบ่งเป็นระบบย่อยๆอะไรบ้าง แล้วแต่ละระบบย่อยมีหน้าที่อะไร , มีบทบาทอะไรในระบบใหญ่ < Component 6 กลุ่มนั่นเอง >

Note : ควรที่จะแยกแยะบทบาทของแต่ละ Component หรือ Sub-system ให้ถูกต้อง เพราะว่าจะทำให้ออกแบบระบบได้ง่ายและดี มีประสิทธิภาพ

The System Engineering Process

ส่วนใหญ่นิยมใช้ Waterfall Model ในการพัฒนาระบบ
แผนภาพนี้จะคล้ายๆกับการทำงานแบบ Waterfall คือ

ในการพัฒนระบบจะมี Process ดังนี้
1. Requirement Definition : เก็บรวบรวมความต้องการ
2. System Design : ออกแบบระบบ
3. Sub-System Development : พัฒนาระบบย่อย
4. System Integration : นำเอาระบบย่อยมาทำการเชื่อมกันให้ทำงานร่วมกัน
5. System Installation : การติดตั้งจะรวมถึงการใช้งานด้วย (System Operation)
6. System Evolution : หลังจากการใช้งานแล้ว จะมีการพัฒนาเป็น Version ใหม่ๆเพื่อให้การทำงานดีขึ้น แก้ไขปัญหาเก่าที่พบ หรือตัดส่วนที่ไม่จำเป็นออก
7. System Decommissioning : ปลดระวางระบบ หรือ เลิกใช้งาน

เพราะฉะนั้นจะคล้ายกับ Waterfall มาก จึงเป็นเตุผลที่มักจะใช้ Waterfall ในการพัฒนาระบบ

อธิบายทีละขั้นของการพัฒนาระบบ

1. System Requirement Definition
คือ การเก็บ Requirement หรือการกำหนดความต้องการของระบบ โดยที่ Requirement ที่เรากำหนดขึ้นมานั้นจะมีอยู่ 3 ลักษณะ

1. Functional Requirement - เป็นการกำหนดว่าระบบของเราจะทำอะไรได้บ้าง โดย Output ที่จะได้ รับคือ Functional Specification (เป็นรายละเอียดบอกว่าจะทำอะไรได้บ้าง) ตย.เช่น การลงทะเบียนเรียนของนักศึกษา จะมีการทำงานอะไรได้บ้างจะระบุออกมาเลย เช่น
- ต้องตรวจสอบสิทธิ์ในการลงทะเบียนได้
- สามารถบันทึกการลงทะเบียนของนักศึกษา
- จะต้องบันทึกผลการเรียนของนักศึกษาได้
- สามารถพิมพ์รายงานของนักศึกษาแต่ละคนได้
- สามารถพิมพ์รายงานสรุปของนักศึกษาทั้งหมดหรือเป็นกลุ่มได้

2. Non-Functional Requirement – ไม่ได้เกี่ยวกับการทำงานของระบบโดยตรง เช่น ข้อความว่า

“ระบบนี้สามารถใช้หน้าจอ interface แบบ Client-Server ถ้านักอยู่สำนักงานทะเบียน หรือถ้าผู้ใช้ไม่ได้นั่งอยู่ในห้องทะเบียน คือใช้จากข้างนอกก็สามารถใช้หน้าจอ interface ที่เป็น web browser ได้ “

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

ที่เราควรแยกให้ออกว่าเป็น Functional หรือ Non-Functional ก็เพระว่าเราจะได้มุ่งเน้นพัฒนาส่วนที่เป็น Functional ก่อน ถ้าเวลาเหลือค่อยไปพัฒนาส่วน Non-Functional ซึ่งจะทำให้โครงการหรือระบบของเรามีโอกาสล้มเหลวน้อยลง เพราะทำส่วนที่สำคัญเสร็จทันตามกำหนดเวลา

3. Unacceptable System Behavior Specified - (สิ่งที่ไม่ต้องการให้เกิดขึ้นในระบบ)

โดยที่มีการกำหนดหรือระบุไว้ใน Requirement ด้วยว่าเราไม่ต้องการให้เกิดเหตุการณ์อะไรขึ้น และถ้าเกิดขึ้นจะมีทางแก้ไขอย่างไร เช่น ถ้า Server ของเราเกิด down ต้อง down ไม่เกิน 5 นาที เป็นต้น

หรือว่า user ไม่สามารถเข้าไปถึงข้อมูลหรือระบบโดยตรงโดยการพิมพ์ที่อยู่ลงใน URL(ระบบ Internet)โดยไม่ต้องผ่านหน้า Login หรือการตรวจสอบสิทธิ์ใช้งาน (เช่น กรณีของ e-mail โดยปกติเมื่อเราระบุ login กับ password เข้าไปแล้ว ที่ช่องURLจะปรากฎเป็นที่อยู่แปลกๆแล้ว parameter เพียบเลย ถ้าเป็นแต่ก่อนจะสามารถเข้าไปถึงโดยตรงโดยไม่ต้องผ่านการ login ก็โดยกรอกไอ้ที่โผล่มาในช่อง URL นั่นแหละ)

หลังจากระบุ Requirement แล้วควรที่จะเขียนจุดประสงค์(Objective)ของระบบไว้ว่าจะเอาระบบไปใช้ทำอะไรด้วย ซึ่งไม่จำเป็นอะไร แต่ถ้าเป็นไปได้ก็ควรเขียนจะดีกว่า เพราะจะทำให้ตรวจสอบในภายหลังได้ง่าย

System Objective แบ่งออกได้เป็น 2 กลุ่ม
1. Functional Objectives – การพัฒนาระบบขึ้นมาต้องการให้ทำอะไรได้บ้างเหมือนกับ Functional Requirement
2. Organizational Objectives – องค์กรต้องการพัฒนาระบบขึ้นมาเพื่ออะไร

System Requirement Problem (ปัญหาที่พบในขั้นตอนการเก็บ Requirement )

1. Requirement เปลี่ยน โดยที่ในการพัฒนาระบบ requirement อาจจะเปลี่ยนแปลงเมื่อไหร่ก็ได้
2. ระยะเวลาในการพัฒนาระบบขึ้นมาจะใช้เวลาประมาณ 6 เดือนถึง 1 ปี และเวลาที่จะใช้ประมาณ 3 ปีรวมทั้งสิ้นโดยเฉลี่ยประมาณ 5-6 ปี (ช่วงชีวิตระบบ) ซึ่งมันมีช่วงชีวิตที่ยาว แต่ในขณะที่เทคโนโลยีมีการพัฒนาโดยตลอดทั้งทางด้าน Hardware และ Communication เพราะฉะนั้น Requirement ก็อาจจะเปลี่ยนไปด้วยถ้าเทคโนโลยีเปลี่ยน
3. การกำหนด Non-Functional Requirement นั้นกำหนดได้ยาก เพราะมันมองเห็นได้ค่อนข้างยากในช่วงต้น โดยส่วนใหญ่แล้ว Non-Functional นั้นจะเห็นได้ชัดในช่วงหลังจากการพัฒนา , ติดตั้ง หรือใช้งานแล้ว

2. System Design

คือ การออกแบบระบบ โดยแนวคิดในการออกแบบที่ดีก็คือ
- หลังจากที่เรารวบรวม Requirement แล้วแบ่งกลุ่ม Requirement ตามความสอดคล้องกันของ Requirement เหล่านั้น
- พอเสร็จก็กำหนดระบบใหญ่ของเราว่าจะมีระบบย่อยอะไรบ้าง
- หลังจากนั้นจับคู่เอา Requirement ไปใส่ให้ตรงกับระบบย่อยที่มันจะแก้ไขหรือตอบสนอง Requirement นั้นๆให้ครบถ้วน ถ้าระบบย่อยไหนซ้ำซ้อนก็ตัดทิ้งซะและถ้า Requirement ไหนไม่ได้รับการตอบสนองก็ให้สร้างระบบย่อยขึ้นมารองรับซะ เพราะฉะนั้นในทางปฎิบัติแล้วทั้ง 3 กลุ่มจะทำพร้อมๆกันนั่นแหละ
- กำหนดหน้าที่ของระบบย่อยว่าทำหน้าที่อะไร
- กำหนด interface ระหว่าง Sub-system ว่าจะสื่อสาร , ประสานงานกันอย่างไรกันให้รู้เรื่อง เช่นระบบสัญญาณเตือนภัยทั้ง 6 Sub-system จะคุยผ่านทาง Alarm Controller เป็นต้น

System Design Problem (ปัญหาในการออกแบบระบบ)

1. เป็นเรื่องยากที่จะแบ่งกลุ่ม Requirement ต่างๆให้ส่วนไหนรับผิดชอบระหว่าง HW , SW หรือคน เพราะมันค่อนข้างก่ำกึ่งว่าอะไรจะรับผิดชอบดีกว่ากัน เราต้องพิจารณาหลายอย่าง เช่น ราคาต้นทุนของ HW ที่จะใช้ในการตรวจสอบจะสูงมากเลยเปลี่ยนมาใช้คนทำแทน
2. ปัญหาที่ยากๆมักจะถูกผลักภาระมาให้ Software เพระ SW มีความยืดหยุ่นสูงกว่า HW และ SW มีความผิดพลาดน้อยกว่าคน พอปัญหาถูกผลักภาระมาให้จะทำให้ SW มีขนาดใหญ่และต้นทุนสูงมากเกินไป
3. Hardware อาจจะไม่เหมาะกับการใช้ Software โดย HW รวมถึง Platform ด้วย เช่น ระบบ E-Learning จะไม่ใช้ของ Microsoft เป็น Server แต่จะใช้ Unix แทน แต่ก็จะไม่สามารถทำในส่วน Steaming ได้เพราะใน Unix ไม่รองรับการทำงานในส่วนนี้ ทำให้ต้องเลือกว่าจะเปลี่ยนไปใช้ของ Microsoft เป็น server แทนหรือเขียนโปรแกรมขึ้นมาใช้เองบน Unix

3. Sub-System Development

- เวลาพัฒนาระบบย่อยแต่ละระบบมักจะพัฒนาแบบคู่ขนานกันไประหว่าง HW , SW
- อาจมีการนำ COTS ( Commercial Off The Shelf หมายถึง SW ที่แพ็คเป็นกล่องวางขายตามห้างหรือเรียกว่า ซอฟท์แวร์สำเร็จรูป เช่น พวก MS Office ) มาใช้ เป็นส่วนหนึ่งของระบบ ขึ้นอยู่กับขั้นตอนการออกแบบ โดยที่เราออกแบบเราจะพิจารณาและทำการตัดสินใจว่าเราจะเอา COT Product มาใช้หรือจะพัฒนาใหม่ดีกว่ากัน เพราะฉะนั้นในขั้นของการพัฒนานี้ก็อาจจะมีการจัดซื้อหรือการพิจารณาเลือกซื้อ SW พวกนี้เข้ามาใช้ด้วย

ปัญหาที่อาจเกิดขึ้น
- การสื่อสารระหว่างทีมพัฒนา อาจจะไม่ดีพอทำให้ไม่ดีพอหรือเข้ากันไม่ได้
- ในการนำระบบไปใช้งานในหน่วยงาน แล้วอาจเกิดอุปสรรคในด้านการเมือง เช่น อยากใช้ระบบไม่ตรงกัน หรือไม่พร้อมใช้งานระบบที่พัฒนาขึ้นมา หรือถ้าต้องมีการปรับเปลี่ยนอะไรก็ตามจะใช้เวลานานมากและหากมีการเปลี่ยนแปลง requirement ก็จะทำให้ SW นี้เสร็จล่าช้าหรือไม่ทันตามกำหนด

4. System Integration

สิ่งที่ควรทำในการ integrate คือควรจะเริ่ม Sub-system เพียงระบบเดียวก่อน โดยเลือกระบบที่สำคัญที่สุดมาก่อน แล้วพอใช้งานได้ไม่มีปัญหาค่อยเอาระบบย่อยที่ 2 มาเชื่อมให้ทำงาน 2 ระบบคู่กันไปเรื่อยๆพอไม่มีปัญหาก็ค่อยเอาระบบย่อยที่ 3 มาเชื่อมต่อ ทำแบบนี้กับระบบย่อยที่เหลือจนหมด (เรียกว่า Incrementally) ซึ่งจะทำให้โอกาสที่ระบบล้มเหลวน้อยลง

5. System Installation and Operation

- System Installation

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

- System Operation

ตรงส่วนนี้ Requirement ที่เราไม่ได้กำหนดไว้ว่ามันจะเกิดขึ้นมา ซึ่งทำให้เราต้องกลับไปออกแบบแก้ไขระบบกันใหม่

ปัญหาที่จะเกิดขึ้น
1. Requirement ที่ไม่คาดคิดหรือลืมจะโผล่ออกมา
2. User ไม่ใช้งานระบบอย่างที่เราออกแบบมา เช่น กรอกข้อมูลผิดตำแหน่ง
3. อาจจะมีปัญหาที่เกิดขึ้นจากการทำงานร่วมกับระบบอื่นๆ

6. System Evolution

หลังจากใช้ระบบไปแล้ว จากนั้นจะต้องมีการพัฒนาตัวใหม่ๆขึ้นมา เพราะเทคโนโลยีมีการเปลี่ยนแปลง หรือ Requirement เปลี่ยนไป โดยที่ Evolution ทำให้เกิด Cost บางอย่างเช่น ต้องมีการนั่งประชุมพิจารณาเรื่องของเทคนิค ต่างๆและเรื่องของธุรกิจด้วย

ปัญหาอีกอย่างหนึ่งที่จะเกิดขึ้นคือ ตอนออกแบบและพัฒนาไม่ได้มีการบันทึกไว้ว่าจุดประสงค์ของ Sub-system มีไว้เพื่ออะไร เพราะฉะนั้นพอถึงเวลาพัฒนาปรับปรุงเพิ่มเติมต้องมานั่งแกะว่าแต่ละส่วนมันทำหน้าที่อะไร

7. System Decommissioning

ไม่ค่อยมีปัญหาอะไร นอกจากว่าจะจัดการกับข้อมูลอย่างไร ถ้ามีระบบใหม่มารองรับจะ Convert ข้อมูลอย่างไรเพื่อให้ไปใช้ได้ต่อ หรือก่อนการสำรองข้อมูลจะมีการConvertให้เป็น Standard เพื่อจะนำไปใช้กับระบบอื่นได้

บรรยายเมื่อ 3 ธค.2544 เทอม 2/44