Chapter 11-12

สรุปบทที่ 11-12

Unit 11

The Design Process

1. User มีความต้องการแบบไหน กิจกรรมอะไร ให้วิเคราะห์

2. มาสร้าง Prototype ออกแบบเป็นกระดาษและถามความต้องการกับ User (ไม่ใช่ End-User)
3. เอาไปประเมินค่ากับ End-User จริงๆ

4. เป็น Prototype Design ที่สามารถกดได้ คลิกได้จริงๆ

5. เอาไปประเมินกับ End-User อีก ที่สามารถใช้ได้จริง

6. สร้างตัวต้นแบบเป็น User Interface ที่ใช้ได้จริงๆ

หลัการประเมิน

Learna bility เรียนรู้ได้ง่าย

Speed of Operation ความเร็วในการประมวลผล ใช้เวลามากน้อยแค่ไหน

Robustness ความคงทนในการใช้งาน การใส่ Char ผิด

Recoverability ความสามารถในการกู้คืน ใช้เวลากี่นาที

Adaptability การปรับใช้

Simple evaluation techniques

1. สร้างเป็นแบบสอบถามให้ User ตอบและประเมินผล

2. เปิด video ให้ User ดูและดูกริยาของ User

3. เขียนโปรแกรมทำหน้าที่แอบเก็บข้อมูลว่า User ได้ทำอะไรย้าง

4. เพิ่มปุ่มเพื่อให้ User กรอกข้อมูลในหน้า User Interface นั้นเลย

Unit12

คำศัพท์

Error การกระทำผิด ค่าจริงที่ได้จากการทำงานไม่ถูกต้อง

Fault ความผิดพลาด ข้อบกพร่อง กระบวนการทำงานของระบบ การประมวลผลซอฟร์แวร์ที่ไม่ปกติ

Failure ล้มเหลว ไม่สามารถทำงานได้

Chapter 6

สรุปบทที่ 6

Requirements engineering processes

เข้าถึง เข้าใจความต้องการของลูกค้าทั้งหมด โดยกิจกรรมหลักๆมีดังนี้

1. สกัดความต้องการ ค้นหาความต้องการ

2. วิเคราะห์ความต้องการเป็นเอกสาร

3. ตรวจสอบ นำมาเขียน และแบ่ง

4. RQ ดูว่าอันไหนควรจะมีการพัฒนาก่อนหรือหลัง

Feasibility studies

1.      การศึกษาความเป็นไปได้ ช่วยตัดสินใจว่าคุ้มค่าหรือไม่

2.      การศึกษาแบบใกล้ชิด ตรวจเช็คว่า

- ว่าระบบจะส่งผลตอบแทนตามเป้าหมาย

- ว่าระบบสามารถทำได้ด้วยเทคโนโลยีปัจจุบัน และไม่เกินงบประมาณ

- ว่าระบบสามารถนำไปใช้ร่วมกับระบบอื่นๆ ที่ใช้อยู่ปัจจุบัน

Feasibility study implementation

1.      ขึ้นอยู่กับการประเมินข้อมูล (ว่าต้องการอะไร) การเก็บข้อมูล การเขียนรายงาน

2.      คำถามของคนในองค์กร

3.      อะไรจะเกิดขึ้นถ้าไม่ได้นำไปใช้?

4.      ปัญหาในกระบวนการปัจจุบันมีอะไรบ้าง?

5.      ระบบใหม่จะช่วยได้อย่างไร?

6.      จะมีปัญหาในการรวบรวมหรือไม่?

7.       สิ่งอำนวยความสะดวกที่จะรองรับระบบที่เสนอขึ้นมามีอะไรบ้าง?

Problems of requirements analysis

1.      Stakeholders ไม่ทราบความต้องการที่แท้จริงของตัวเอง

2.      Stakeholders แจ้งความต้องการด้วยภาษาที่เข้าใจเองฝ่ายเดียว

3.      Stakeholders มีความต้องการขัดแย้งกันเอง

4.      องค์กรและปัจจัยการเมือง อาจส่งผลถึงความต้องการ

5.       ความต้องการเปลี่ยนไปในระหว่างการทำวิเคราะห์ Stakeholders คนใหม่ เข้ามามีส่วนร่วมทำให้ภาวะทางธุรกิจเปลี่ยนไป

Process activities

1.      การค้นหาความต้องการ

2.      พูดคุยสอบถามผู้มีส่วนได้เสีย เพื่อค้นหาว่าเขาต้องการอะไรบ้าง ความต้องการหลักๆ ก็จะพบได้จากการพูดคุยนี้

3.      การจัดชั้นลำดับความสำคัญ

4.      จัดกลุ่มความต้องการที่เกี่ยวข้องกันไว้ ในกลุ่มเดียวกัน

5.      จัดลำดับความสำคัญก่อนหลัง

6.      อะไรมีความสำคัญต้องการทำก่อน อะไรที่ขัดแย้งกันต้องขจัดออกไป

7.      ทำเอกสาร

8.       สิ่งที่จำเป็นต้องทำต้องบันทึกไว้เป็นลายลักษณ์อักษร และเป็นข้อมูลป้อนใส่ในการทำโปรแกรมครั้งต่อไป

ATM stakeholders

1.      ลูกค้าของธนาคาร

2.      ตัวแทนจากต่างธนาคาร

3.      ผู้จัดการธนาคาร

4.      เจ้าหน้าที่ที่เคาน์เตอร์

5.      ผู้บริหารอ่านข้อมูล

6.      ผู้จัดการด้านความปลอดภัย

7.      ฝ่ายการตลาด

8.      วิศวกรผู้ดูแลฮาร์ดแวร์และซอฟแวร์

9.      ผู้ออกกฎหมายควบคุมธนาคาร

Interviewing

1.      การสัมภาษณ์อย่างเป็นทางการหรือส่วนตัว ทีม Requirements จะถามคำถามเกี่ยวกับระบบปัจจุบันและระบบที่ต้องการใหม่

2.      การสัมภาษณ์แบ่งเป็น 2 ชนิด

3.      แบบปิด คือ เตรียมคำถามมาให้ตอบ

4.      แบบเปิด คือ ไม่มีการกำหนดวาระ และคำถามจะเป็นการถามสด โดยตรงจากผู้เป็นเจ้าของระบบ

Chapter 9

สรุปบทที่ 9

สถาปัตยกรรมของระบบแบบกระจาย

สถาปัตยกรรมแบบ Client-server เป็นการกระจายบริการซึ่งถูกเรียกใช้โดย เครื่องลูก (Client)

จากเครื่องแม่ข่าย (Server) ในที่นี้จะใช้ทับศัพท์คือ Client และ Server

สถาปัตยกรรมการกระจาย.

Middleware คือซอฟต์แวร์ที่ใช้ในการจัดการ และสนับสนุน Components ของระบบแบบ

กระจาย โดยทัวไปจะเป็นซอฟต์แวร์ที่ต้องจัดซื้อ จัดหา เพิ่มเติมจากระบบที่จะพัฒนา

ตัวอย่าง เช่น การแสดงการประมวลผลข้อมูล การแปลงข้อมูล (Data converters) หรือ การ

ควบคุมการสื่อสาร เป็นต้น

สถาปัตยกรรมแบบ (Multiprocessor) เป็นระบบที่ใช้หลายๆหน่วยประมวลผลทํางานพร้อมๆกัน

ในหลายๆงาน เป็นระบบที่มความซับซ้อนน้อยที่สุด เพราะไม่ต้องอาศัยเครือข่ายใดๆ

สถาปัตยกรรมแบบ Client-server มีการทํางาน Application และ Presentation ที่เครื่องไคลเอนต์

สถาปัตยกรรมของการทํางานมี 3 ชั้นคือ

• Presentation layer : เป็นชั้นที่ใช้ในการนําเสนอผล และการนําข้อมูลเข้าสู่ระบบ

• Application processing layer : เป็นการชั้นที่มีการประมวลผลตามคําสั่งในโปรแกรม

• Data management layer : เป็นชั้นที่ใช้บริหาร จัดการข้อมูล

แสดงภาพสถาปัตยกรรมแบบกระจาย

สถาปัตยกรรมแบบ Thin และ Fat Clients

Thin-client model: เป็นระบบที่ให้ client มีการประมวลผลน้อยที่สุด โดยการใช้เพียงแค่

browser ซึ่งทําหน้าที่แสดงผล (Presentation) เท่านั้น การประมวลผลส่วนใหญ่จะอยู่ที่เครื่องแม่

ข่าย (Server) รวมทั้ง Code ของซอฟต์แวร์ด้วย ทั้ง Application processing และ การจัดการข้อมูล

(Data management) ระบบนี้จะมีความสะดวกในการบริหารจัดการ เพราะสามารถทําได้จาก

ส่วนกลาง ตัวอย่างของระบบนี้เช่น การใช้ http://www.ในระบบอินเตอร์เน็ต เป็นต้น ข้อเสียของ

ระบบนี้คือเครื่องแม่ข่ายจะทํางานหนักมาก

Fat-client model: เป็นระบบที่ให้เครื่อง Client ทํางานเป็นส่วนใหญ่ ทั้งการแสดงผล

(Presentation) และการประมวลผลการทํางาน (Application processing) ส่วนเครื่องแม่ข่าย

(server) ทําหน้าที่ data management คือจัดเก็บ และ ค้นหาข้อมูลเท่านัน ซอฟต์แวร์ หรือ code จะ

ถูกติดตั้งที่เครือง client ซึ่งจะเป็นการกระจายการประมวลผล ไปทั้งที่เครื่อง client และเครื่อง

server แต่จะหนักไปที่ client จึงเรียกว่า fat-client ข้อดีของระบบนี้คือเครื่อง แม่ข่ายไม่จําเป็นต้อง

มีขนาดใหญ่มาก แต่เครื่อง client จะต้องมีประสิทธิภาพที่ดี เพราะจะต้องทําการประมวลผลที่

เครื่อง client ข้อเสียคือการบริหารจัดการค่อนข้างยาก เพราะจะต่องติดตั้งซอฟต์แวร์ทั้งที่เครื่อง

แม่ข่าย และเครื่องลูกข่ายทั้งหมด

สรุป

สถาปัตยกรรมการกระจายการประมวลผล ทําให้สามารถขยายระบบไปได้โดยไม่จากัด

และถ้าใช้ควบคู่กับการกระจาย Object ด้วยแล้วจะทําให้ผู้พฒนาสามารถจะดําเนินการผลิต

ซอฟต์แวร์ได้อย่างรวดเร็ว เพราะไม่ต้องไปเริ่มต้นทํางานใหม่ทกครั้ง ทั้งการใช้ Object ที่มีอยู่

แล้ว หรือการใช้ Object ร่วมกับผู้ผลิตรายอื่น โดยผ่านระบบเครือข่าย การทํางานในลักษณะ

ดังกล่าวจําเป็นต้องมีมาตรฐานเพื่อให้ระบบต่างๆ สามารถเชื่อมต่อกันได้อย่างสมบูรณ์ ใน

ปัจจุบันมี 2 มาตรฐานที่นิยมใช้คือ CORBA และ DCOM ซึ่ง CORBA สนับสนุนระบบเปิด เช่น

UNIX และ ภาษา C++ และ Java โดยอาศัยภาษา IDL ซึ่งจะบอกวิธีการเชื่อมต่อและแปลงข้อมูล

ให้แต่ละวัตถุสามารถเชื่อมโยงกันได้ เมือมีวัตถุจํานวนมากในระบบจําเป็นต้องใช้ ORB ในการ

บริหารจัดการ Object ในเครือข่ายเดียวกัน และ ORB สามารถเชื่อมโยงกันเองได้เมื่อระบบมี

ความซับซ้อนมากขึ้น

Chapter 7

สรุปบทที่ 6

Requirements engineering processes

เข้าถึง เข้าใจความต้องการของลูกค้าทั้งหมด โดยกิจกรรมหลักๆมีดังนี้

1. สกัดความต้องการ ค้นหาความต้องการ

2. วิเคราะห์ความต้องการเป็นเอกสาร

3. ตรวจสอบ นำมาเขียน และแบ่ง

4. RQ ดูว่าอันไหนควรจะมีการพัฒนาก่อนหรือหลัง

Feasibility studies

1.      การศึกษาความเป็นไปได้ ช่วยตัดสินใจว่าคุ้มค่าหรือไม่

2.      การศึกษาแบบใกล้ชิด ตรวจเช็คว่า

- ว่าระบบจะส่งผลตอบแทนตามเป้าหมาย

- ว่าระบบสามารถทำได้ด้วยเทคโนโลยีปัจจุบัน และไม่เกินงบประมาณ

- ว่าระบบสามารถนำไปใช้ร่วมกับระบบอื่นๆ ที่ใช้อยู่ปัจจุบัน

Feasibility study implementation

1.      ขึ้นอยู่กับการประเมินข้อมูล (ว่าต้องการอะไร) การเก็บข้อมูล การเขียนรายงาน

2.      คำถามของคนในองค์กร

3.      อะไรจะเกิดขึ้นถ้าไม่ได้นำไปใช้?

4.      ปัญหาในกระบวนการปัจจุบันมีอะไรบ้าง?

5.      ระบบใหม่จะช่วยได้อย่างไร?

6.      จะมีปัญหาในการรวบรวมหรือไม่?

7.       สิ่งอำนวยความสะดวกที่จะรองรับระบบที่เสนอขึ้นมามีอะไรบ้าง?

Problems of requirements analysis

1.      Stakeholders ไม่ทราบความต้องการที่แท้จริงของตัวเอง

2.      Stakeholders แจ้งความต้องการด้วยภาษาที่เข้าใจเองฝ่ายเดียว

3.      Stakeholders มีความต้องการขัดแย้งกันเอง

4.      องค์กรและปัจจัยการเมือง อาจส่งผลถึงความต้องการ

5.       ความต้องการเปลี่ยนไปในระหว่างการทำวิเคราะห์ Stakeholders คนใหม่ เข้ามามีส่วนร่วมทำให้ภาวะทางธุรกิจเปลี่ยนไป

Process activities

1.      การค้นหาความต้องการ

2.      พูดคุยสอบถามผู้มีส่วนได้เสีย เพื่อค้นหาว่าเขาต้องการอะไรบ้าง ความต้องการหลักๆ ก็จะพบได้จากการพูดคุยนี้

3.      การจัดชั้นลำดับความสำคัญ

4.      จัดกลุ่มความต้องการที่เกี่ยวข้องกันไว้ ในกลุ่มเดียวกัน

5.      จัดลำดับความสำคัญก่อนหลัง

6.      อะไรมีความสำคัญต้องการทำก่อน อะไรที่ขัดแย้งกันต้องขจัดออกไป

7.      ทำเอกสาร

8.       สิ่งที่จำเป็นต้องทำต้องบันทึกไว้เป็นลายลักษณ์อักษร และเป็นข้อมูลป้อนใส่ในการทำโปรแกรมครั้งต่อไป

ATM stakeholders

1.      ลูกค้าของธนาคาร

2.      ตัวแทนจากต่างธนาคาร

3.      ผู้จัดการธนาคาร

4.      เจ้าหน้าที่ที่เคาน์เตอร์

5.      ผู้บริหารอ่านข้อมูล

6.      ผู้จัดการด้านความปลอดภัย

7.      ฝ่ายการตลาด

8.      วิศวกรผู้ดูแลฮาร์ดแวร์และซอฟแวร์

9.      ผู้ออกกฎหมายควบคุมธนาคาร

Interviewing

1.      การสัมภาษณ์อย่างเป็นทางการหรือส่วนตัว ทีม Requirements จะถามคำถามเกี่ยวกับระบบปัจจุบันและระบบที่ต้องการใหม่

2.      การสัมภาษณ์แบ่งเป็น 2 ชนิด

3.      แบบปิด คือ เตรียมคำถามมาให้ตอบ

4.      แบบเปิด คือ ไม่มีการกำหนดวาระ และคำถามจะเป็นการถามสด โดยตรงจากผู้เป็นเจ้าของระบบ

Chapter 5

สรุปบทที่ 5

กระบวนการที่ทำให้ SE เข้าใจและเข้าถึงลูกค้าอย่างแท้จริง

1. ค้นหาความต้องการ

2. วิเคราะห์

3. กำหนดความต้องการ

4. ตรวจสอบ

ความต้องการ

ถือเป็นวัตถุดิบสําคัญในการผลิตซอฟต์แวร์เพือสร้างข้อกําหนดความต้องการของลูกค้าเพื่อให้ซอฟต์แวร์ทถูกพัฒนาขึ้นตรงกับความต้องการที่แท้จริง

จําแนกความต้องการด้านซอฟต์แวร์ได้เป็ น 2ระดับ คือ

1. ความต้องการของผู้ใช้ (User)

2. ความต้องการด้านระบบ (System Requirement)

ความต้องการด้านซอฟต์แวร์ แบ่งออกเป็ น 3 ประเภท ได้แก่

1. ความต้องการทีเป็ นหน้าทีหลัก(Functional Requirement)

เป็นความต้องการทีเป็นหน้าทีหลัก ซึ่งทําหน้าทีใดๆตามทีกําหนดไว้ในส่วนการทํางานหรือบริการทีซอฟต์แวร์นันควรมี

2. ความต้องการทีไม่ใช่หน้าทีหลัก (Non-Functional Requirement)

เป็ นความต้องการทีไม่เกียวข้องโดยตรงกับหน้าทีหรือฟังก์ชันหลักของระบบ เช่นความต้องการด้านผลิตภัณฑ์ความต้องการขององค์กร และความต้องการจากปั จจัยภายนอก

3. ความต้องการด้านธุรกิจ (Domain Requirement)

เป็นความต้องการทีเกี่ยวข้องกับงานหลักของระบบธุรกิจทีต้องการซอฟต์แวร์มาสนับสนุนโดยเฉพาะซึ่งอาจเป็ นเงือนไขของฟังก์ชันใดๆหรือเงือนไขที่ใช้คํานวณหาผลลัพธ์ใดๆ ของระบบ

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

หมายถึง กระบวนการทีจะทําให้วิศวกรรมซอฟต์แวร์เข้าใจและเข้าถึงความ้องการของลูกค้าได้อย่างแท้จริง

ด้วยการสกัดความต้องการ ตรวจสอบและนิยามความต้องการเพื่อนําไปสร้างเป็นข้อกําหนดความต้องการด้านระบบหรือซอฟต์แวร์

เป้าหมายของวิศวกรรมความต้องการ ก็คือ

การสร้างและบํารุงเอกสารข้อกําหนดความต้องการทั้งทางด้านระบบและด้านซอฟต์แวร์ให้เป็นเอกสารทีมีคุณภาพทีสุด

ข้อแนะนำในการเขียนความต้องการ

1. เขียนเป็นลักษณะโครงสร้างที่เป็นมาตรฐานนำไปใช้ได้ทุก RQ

2. ใช้ภาษาคงเส้นคงวา และมีศัพท์ 2 คำ คือจะต้อง และควรจะ

3. การใช้ตัวบางตัวหนา

4. หลีกเลี่ยงการใช้ศัพท์เทคนนิคเพราะมีคนหลายกลุ่ม

Sequence Diagram ใช้จําลองภาพเชิงกิจกรรม (Dynamic Model หรือ Behavioral Model)

- การจําลองกระบวนการที่ทําให้เกิดกิจกรรมรวมของระบบ

- กิจกรรมรวมของระบบ เกิดจาก ชุดของกิจกรรม (หลายๆ กิจกรรม)

- 1 กิจกรรม เกิดจาก Object หนึ่งมีการโต้ตอบกับอีก Object หนึ่ง

ประโยชน์ของ Sequence Diagram

- ช่วยให้รู้ว่า มี Function ขาดหายไปจาก Class Diagram หรือไม่

- ช่วยให้พิจาณาได้ว่าควรเพิ่มเติม Function ใน Class Diagram อีกหรือไม่

- ช่วยให้ปรับปรุง Class Diagram ได้สมบูรณ์ยิ่งขึ้น

ตัวอย่าง 

Sequence Diagram

Chapter 8

สรุปบทที่ 8

Software architecture

- กระบวนการออกแบบที่ระบุหา sub-systems ที่ประกอบเป็ นsub-system และ framework สําหรับการควบคุมและสื่ อสารระหว่างsub-sub-system 

เรียกว่า architectural design.

- ผลจากกระบวนการออกแบบเป็ นรายละเอียดของ software architecture.

Architectural design

- อยู่ในระยะแรกของกระบวนการออกแบบ

- เป็นตัวแทนของการเชื่อมโยงระหว่าง specification และ design

-ปกติแล้วทําไปพร้อมๆกับการทํา specification

- เป็นการระบุหา system components และสื่ อระหว่างกัน

System structuring

- เกี่ยวกับการแยกระบบออกเป็ น ระบบย่อยที่โต้ตอบกัน

- Architectural design ปกติแล้วแสดงด้วย ผังรูปเหลี่ยมบ่งบอกโครงสร้างระบบ

- มีโมเด็ลเฉพาะแสดงให้เห็นว่า sub-system แบ่งข้อมูลกันอย่างไรและโต้ตอบกันเกิดขึ้นอย่างไร

Architectural design decisions

- มี generic application ทีจะนํามาใช้หรื อไม่?

- ควรจะกระจายระบบออกอย่างไร?

- สถาปัตยกรรมรู ปแบบใหนจึงจะเหมาะสม?

- ควรใช้แนวทางใดเพื่อวางโครงสร้างระบบ?

- ควรจะแบ่งย่อยระบบออกเป็นโมดุลอย่างไร?

- ควรใช้แผนการควบคุมอะไร?

- ควรจะประเมิน แบบสถาปัตย์ อย่างไร?

- ควรจะบันทึก แบบสถาปัตย์ อย่างไร?

Architectural styles

- โมเด็ลสถาปัตย์ ของระบบอาจสอดคล้องกับ โมเด็ลหร อแบบ โดยทัวไป

- ความรู้ของแบบเหล่านี้ ทําให้เข้าใจปัญหา การสร้างสถาปัตย์กรรมให้ระบบ

- อย่างไรก็ดี ระบบใหญ่ๆจะมีีลกษณะต่างกัน และไม่เป็ นไปไปตามแบบสถาปัตย์กรรมเดี่ยว

Architectural models

- ใช้สาหรับบันทึก แบบสถาปัตย์

- โมเด็ลโครงสร้างสถิต ใช้แสดงชิ้นส่ วนสําคัญๆของระบบ

- โมเด็ลกระบวนการจลน์ ใช้แสดงโครงสร้างกระบวนการของระบบ

- โมเด็ลการโต้ตอบ ใช้อธิบายการโต้ตอบระหว่างระบบย่อย

- โมเด็ลความสัมพันธ เช่น data-flow ใช้แสดงความสัมพันธระหว่างระบบย่อย (sub-system)

- โมเด็ลแบบกระจาย ใช้แสดงการกระจายระบบย่อยไปตามเครื่องคอมพิวเตอร์

Chapter 3-4

สรุปบทที่ 3-4

Systems Engineering

เป็นเรื่องของคนในองค์กร บุคคลที่ทำหน้าที่ออกแบบ สร้าง ซ่อมบำรุง ซอฟต์แวร์ และฮาร์ดแวร์ เพื่อให้ระบบดำเนินงานได้ตามต้องการ

Emergent properties *ความน่าเชื่อถือ เป็นคุณสมบัติของระบบ

สามารถวัดได้จาก

1. วัดน้ำหนักความสำคัญของระบบ

2. วัดความเชื่อถือของระบบ

3. วัดความสามารถในการใช้งานจริง

System Engineering Process *โปรเซส วิศวกรรมระบบ มีอยู่ 7 โปรเซส

1. System requirement definition ขั้นตอนการเก็บรวบรวมความต้องการของระบบ 

มี 3 ลักษณะ คือ

1 Functional requirement ฟังก์ชันการทำงานของระบบมีอะไรบ้าง

2 Non-Functional requirement คุณสมบัติที่ไม่เกี่ยวข้อกับการทำงานของระบบ

ที่แท้จริง

3 Unacceptable สิ่งที่ไม่ต้องการให้เกิดขึ้นกับระบบ เช่น ไฟดับ Server down เป็นต้น

ปัญหาที่พบในการเก็บความต้องการ

1. ความต้องการเปลี่ยนโดยที่ระบบยังพัฒนาไม่เสร็จ อาจเกิดจากเวลาเปลี่ยนความ

ต้องการของคนเปลี่ยนตามเวลา เพราะเทคโนโลยีเปลี่ยน

2. ระยะเวลาในการพัฒนานาน ฮาร์ดแวร์เปลี่ยน ซอฟต์แวร์เปลี่ยน เทคโนโลยีเปลี่ยน

3. กำหนด Non-functional ได้ยาก เพราะสามารถมองเห้นได้เมื่อใช้งานไปแล้วเท่านั้น

2. System design ขั้นตอนการออกแบบระบบ มี 5 ขั้นตอน

1. รวบรวมความต้องการมาแบ่งกลุ่มเป็นส่วนๆ

2. กำหนดว่าระบบใหญ่ควรมีระบบย่อยอะไรบ้าง

3. จับคู่ความต้องการเข้ากับระบบย่อย

4. กำหนดหน้าที่ของระบบย่อย

5. กำหนดส่วนติดต่อระหว่างระบบย่อยว่ามีการเชื่อมต่อ สื่อสารกันอย่างไร

ปัญหาของการออกแบบระบบ

1. ไม่รู้ว่าใครเป็นผู้รับผิดชอบ

2. ปัญหาที่ยาก จะถูกผลักดันให้เป็นหน้าที่ของซอฟต์แวร์ ทำให้ซอฟต์แวร์มีขนาดใหญ่และ

ต้นทุนที่สูง

3. ฮาร์ดแวร์ ซอฟต์แวร์และ Platform ไม่เหมาะกัน เช่น Windown, Max, Linux

3. Sub system development ขั้นตอนการพัฒนาระบบ

- การพัฒนามักจะพัฒนาแบบคู่ขนานระหว่างฮาร์ดแวร์ ซอฟต์แวร์ และ Communication 

- การพัฒนามักใช้ซอฟต์แวร์สำเร็จรูปมาใช้

- ระหว่างทีมพัฒนาในองค์กรอาจเกิดอุปสรรคได้

4. System integration ขั้นตอนการนำระบบย่อยมารวมกัน

เริ่มจากการนำ Sub system ที่สำคัญที่สุดก่อน นำมาทำงานร่วมกัน เมื่อทำงานได้ก็นำ Sub 

system ต่อไป ทำไปเลื่อยๆ การรวมระบบในรูปแบบนี้จะทำให้ระบบล้ม หรือ เกิดความผิดพลาด

น้อยลง

5. System installation ขั้นตอนการติดตั้งและนำไปใช้

ปัญหาการติดตั้ง

1. สภาพแวดล้อมไม่เหมาะสม ไม่อำนวย

2. คนต่อต้านการนำระบบใหม่ไปใช้งาน เช่น กลัวหมดความสำคัญ

3. ระบบใหม่ที่พัฒนาขึ้นต้องทำงานคู่ขนานกับระบบเก่า ระบบอาจเข้ากันได้ลำบาก

4. พื้นที่การติดตั้งไม่เพียงพอ

5. การวางแผนอบรมการใช้งานระบบ

ปัญหาการนำไปใช้งาน

1. ความต้องการที่ไม่คาดคิดจะโผล่ออกมา เมื่อพัฒนาเสร็จสิ้นแล้ว

2. ผู้ใช้งาน ไม่ใช้ระบบที่เราออกแบบ กรอกข้อมูลผิดตำแหน่ง

3. เวลาทำงานร่วมกับระบบอื่นอาจมีปัญหาได้

- ปัญหาทางกายภาพ

- ปัญหาการแปลงข้อมูล

6. System evolution ขั้นตอนการปรับปรุงระบบ

เมื่อใช้งานไปแล้วต้องมีการพัฒนาโปรแกรมรุ่นใหม่ออกมา เพื่อให้มีการพัฒนาตาม 

ฮาร์ดแวร์ ซอฟต์แวร์ และ Technology ใหม่ๆ เมื่อปรับปรุงจะเกิดค่าใช้จ่าย

7. System decommissioning ขั้นตอนการปลดละวาง เลิกใช้งาน

ปัญหาการเชื่อมโยงระหว่าง Database ตัวใหม่กับตัวเก่า

Chapter 1

สรุปบทที่ 1

Software Cost (ต้นทุนของซอฟต์แวร์)

คนส่วนมากจะคิดว่าฮาร์ดแวร์มีค้นทุนสูงว่าซอฟต์แวร์ แต่ที่ตริงแล้วการใช้งานซอฟต์แวร์ที่มีลิขสิทธิ์นั้นมีต้นทุนค่าใช้จ่ายที่แพงกว่าฮาร์ดแวร์

1. ต้นทุนหรือค่าใช้จ่ายในการปรับเปลี่ยน บำรุงรักษาซอฟต์แวร์จะเท่ากับหรือใกล้เคียงกับต้นทุน

ของฮาร์ดแวร์

2. ต้นทุนในการบำรุงรักษาซอฟต์แวร์จะมีค่ามากกว่าการพัฒนาซอฟต์แวร์ขึ้นมาใหม่

3. นักวิศวกรรมซอฟต์แวร์จะต้องมีการวิเคราะห์ และพิจารณาในการบำรุงรักษา หรือปรับเปลี่ยน

ระบบโดยพิจารณาจากต้นทุนเป็นหลัก

ซอฟต์แวร์ คืออะไร ?

1. ซอฟต์แวร์ คือ ชุดคำสั่งที่ใช้ในการควบคุมการทำงานของคอมพิวเตอร์ หรือเอกสารประกอบ

2. ซอฟต์แวร์ คือ โปรแกรมคอมพิวเตอร์ และเอกสารประกอบ

ซอฟต์แวร์ที่ ผลิตขึ้นมี 2 ลักษณะ คือ

1. พัฒนาขึ้นเพื่อใช้งานภาพในองค์กร

2. พัฒนาขึ้นเพื่อจำหน่ายในเชิงพาณิชย์

Software Engineering ?

คือ การนำหลักการทางวิศวกรรมมาใช้กับทุกขั้นตอนของการของการพัฒนาซอฟต์แวร์ ตั้งแต่ก่อนพัฒนา จนได้ซอฟต์แวร์

ความท้าทายทางด้านวิศวกรรมซอฟต์แวร์

1. Legacy การพัฒนาโปรแกรมใหม่ให้สามารถทำงานร่วมกับโปรแกรมเดิมได้

2. Heterogeneity ความไม่เข้ากันของฮาร์ดแวร์และซอฟต์แวร์

3. Delivery ความจำกัดด้านเวลา ความผิดพลาดในเรื่องของเวลา

ความแตกต่างของ Computer Science และ Software Engineering

1. Computer Science จะเน้นทางด้านทฤษฎี หลักการความรู้พื้นฐานที่จะเป็นต่อการนำไปประยุกต์

ใช้ในชีวิตประจำวัน

2. Software Engineering จะเน้นการปฎิบัติจริงโดยนำ ทฤษฎีของ Computer Science มาใช้ในทุก

ขั้นตอนของการผลิตซอฟต์แวร์

ความแตกต่างระหว่าง System Engineering และ Software Engineering

- System Engineering จะเกี่ยวข้องกับทุกๆ ขั้นตอนของการพัฒนาระบบ ทั้งด้าน ฮาร์ดแวร์ ซอฟต์แวร์ และโพรเสซ

- System Engineering จะเกี่ยวข้องกับการกำหนดรายละเอียดของระบบ การออกแบบระบบทางด้านสถาปัตยกรรม การรวมระบบและพัฒนา

Software Process คือ กระบวนการที่พัฒนาซอฟต์แวร์ให้ประสบความสำเร็จ แบ่งออกเป็น 4 ขั้นตอน

1. Specification การกำหนดความต้องการของระบบ โดยสอบถามจาก User

2. Development การพัฒนาระบบ รวมถึงการออกแบบระบบ

3. Validation การทวนสอบ คือขั้นตอนของการทดสอบการทำงานของระบบว่าตรงตามความ

ต้องการของผู้ใช้งานหรือไม่

4. Evolution การปรับปรุงระบบ ในอนาคตเมื่อความต้องการในการใช้งานระบบเปลี่ยนไป จะต้อง

ทำงานปรับปรุงระบบให้ตรงกับความต้องการที่เปลี่ยนไปด้วย

Software Process Model คือ แบบจำลองในการพัฒนาซอฟต์แวร์ มีอยู่ 3 มุมมอง(แบบ)

1. Workflow มุมมองเน้นกิจกรรมของโปรแกรม นิยมเขียนด้วย Flowchart

2. Data-Flow มุมมองเกี่ยวข้องกับข้อมูลเป็นหลัก นิยมเขียนด้วย Data flow Diagram

3. Role/Action มุมมองที่ให้คววามสำคัญว่าใครทำอะไร นิยมเขียนด้วย User case Diagram

แบบจำรองทั่วๆ ไป เช่น

1. Waterfall แบบจำลองน้ำตก

2. Evolutionary development แบบจำลองของการพัฒนาแล้วเพิ่มเติมไปเลื่อยๆ

3. Formal transformation แบบจำลองที่เป็นระเบียบชัดเจนผิดพลาดไม่ได้

4. Integration from reusable มุมมองการนำ Component กลับมาใช้ใหม่

CASE (Computer-Aided Software Engineering) คือ ซอฟต์แวร์ที่พัฒนาขึ้นมาเพื่อใช้สร้างซอฟต์แวร์

- Upper-CASE ขั้นตอนการพัฒนาในช่วงแรก เครื่องมือที่ใช้ เช่น MS-Project, Visio, E-Draw

- Lower-CASE ขั้นตอนการเขียนโปรแกรม การทดสอบ เครื่องมือที่ใช้ เช่น MS-Studio, Eclipse,

Edit Plus 

คุณสมบัติของซอฟต์แวร์ที่ดี

1. Maintainability ต้องมีความสามารถในการบำรุงรักษา จะต้องมีการเปลี่ยนแปลงเพื่อตอบสนองต่อ

ความต้องการของผู้ใช้ที่เปลี่ยนแปลงไป การเปลี่ยนแปลงจะต้องไม่ส่งผลกระทบต่อการทำงาน

ของระบบ

2. Dependability ความสามารถในการพึ่งพา ความน่าเชื่อถือ ต้องผ่านการตรวจสอบในทุกฟังก์ชัน

3. Efficiency ความสามารถในด้านประสิทธิภาพ เช่น ประหยัดทรัพยากรของเครื่อง

4. Usability ความสามารภในการใช้งาน เช่น ความสะดวก ความปลอดภัย สามารถเรียนรู้การใช้งาน

ได้เร็ว

ความรับผิดชอบทางจริยธรรมของนักวิศวกรรมซอฟต์แวร์

1. ความลับ นักวิศวกรรมซอฟต์แวร์ จะต้องรักษาความลับของลูกค้าและนายจ้างแม้จะไม่มีการลง

นามเป็นรายลักษณ์อักษร

2. ความสามารถ ไม่อวดความสามารถที่ไม่เป้นจริงและไม่ควรรับงานที่ไม่ถนัด

3. เคารพสิทธิทางปัญญา จะต้องระมัดระวังไม่ละเมิดกฎหมาย

4. ไม่ควรใช้ความถนัดทางด้านเทคนิคการใช้งานคอมพิวเตอร์ ผิดวัตถุประสงค์ เช่น ปล่อยไวรัส

ACM ได้ร่วมมีกับ IEEE กำหนด Code of Ethics ขึ้น ซึ่งก็คือประมวลเบื้องจ้นที่นักวิศวกรรมซอฟต์แวร์ต้องปฎิบัติร่วมกัน มีทั้งหมด 8 ข้อ 

1. Public จะต้องทำหน้าที่โดยคำนึงถึงผลประโยชน์ส่วนรวมด้วย

2. Client and Employer ต้องคำนึงถึงความต้องการของลูกค้าและนายจ้าง

3. Product จะต้องผลิตผลงานด้วยมาตรฐานสูงสุดตามหลักวิชาการ

4. Judgment ต้องตัดสินใจได้อย่างอิสละ และเป็นตัวของตัวเอง

5. Management หากนักวิศวกรรมซอฟต์แวร์ เป็นผู้บริหารหรือผู้จัดการจะต้องสนับสนุนและเผยแพร่

หลักจริยธรรม

6. Profession ต้องยึดมั่นในคุณธรรม รักษาชื่อเสียงในวิชาชีพของตนเอง

7. Colleagues ต้องมีความเป็นธรรมและสนับสนุนเพื่อนร่วมงาน

8. Self จะต้องพัมนาตนเองอยู่เสมอ