SRS

UML (Unified Modeling Language) เป็นเครื่องมือใหม่ที่ได้รับการยอมรับเพิ่มขึ้นตลอดเวลา เริ่มประยุกต์ใช้กับระบบงานมากขึ้น เพราะเป็นเครื่องมือที่มีความหลากหลายในการแสดงแบบซอฟต์แวร์ เป็นโมเดลมาตรฐานที่ใช้หลักการออกแบบ OOP (Object Oriented Programming)

Use Case Diagram

Sequence Diagram

Chapter 11-12

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 9

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 8

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 7

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 6

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 5

Chapter 5 

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 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 2

นายธีรภัทร์ มังคลาด ID: 520702477896

สรุปบทที่ 2

The Software Process

ขั้นตอนการพัฒนาระบบ สามารถแบ่งออกได้เป็น 4 ขั้นตอน

1. Specification กำหนดความต้องการ เป็นขั้นตอนที่กำหนดว่า Program ทำอะไรได้บ้าง ต้องการอะไรบ้าง

2. Design เป็นขั้นตอนการออกแบบระบบ ตามความต้องการที่ได้กำหนดเอาไว้ในข้อที่ 1

3. Validation การทดสอบ ทวนสอบ การทำงานหรือฟังก์ชันของระบบว่าตรงกับความต้องการของลูกค้าหรือไม่

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

แบบจำลองที่ใช้ในการพัฒนาระบบมี 4 แบบจำลอง

1. Waterfall Model (แบบน้ำตก)

2. Evolutionary Development (ปรังปรุง Version ไปเรื่อยๆ จนลูกค้าพอใจจึงจะเสร็จ)

3. Component-based software engineering (การนำ Component ที่มีอยู่แล้วกลับมาใช้ใหม่)

4. Process iteration (การพัฒนาซ้ำๆ)

1. Waterfall Model

Waterfall Model

เป็นแบบจำลองที่ประกอบขึ้นด้วยขั้นตอนที่ต่อเนื่องเป็นลำดับ ตั้งแต่ลำดับแรกจนถึงลำดับสุดท้ายว่ามีอะไรบ้าง ไหลจากที่สูงลงสู่ที่ต่ำ สามารถย้อนกลับไปแก้ไขในขั้นตอนก่อนหน้าได้ (ข้อเสีย)แต่จะมีความยุ่งยากในการในการปรับเปลี่ยน เช่น ต้องการในขั้นตอนที่ 3 ก็ต้องย้อนกลับไปขั้นตอนที่ 1, 2 ด้วย

2. Evolutionary development

Evolutionary Model

การพัฒนาแบบนี้ทำให้เกิดการปรับปรุง ปรับเปลี่ยนความต้องการให้อยู่ในรูปแบบของ Version มี 4 ขั้นตอน

1. Requirement วิเคราะห์ความต้องการ

2. System Design ออกแบบระบบ

3. Coding and Testing ขั้นตอนการเขียนและทดสอบระบบ

4. Assignment การประเมินผล

ปัญหา

1. ขาดความชัดเจนในการทำงาน

2. ระบบที่สร้างขึ้นมาไม่ค่อยเป็นระบบเท่าไร

3. ผู้ใช้ระบบ ต้องมีความชำนาญสุูง

ข้อเสีย

1. อาจจะรบกวนเวลาทำงานของลูกค้า ทำให้เกิดความลำคาญใจ

2. บอกความคืบหน้าในการทำงานลำบาก

การนำแบบจำลองไปใช้

1. ใช้กับระบบเล็กหรือขนาดกลาง

2. นำไปใช้ในส่วนของระบบงานขนาดใหญ่

3. นำไปใช้ในโครงงานที่มีอายุการดำเนินงานสั้นๆ

3. CBSE (Component-Based Software Engineering)

ข้อดี

1. รวดเร็วขึ้น

2. ประหยัดต้นทุน

3. ระบบมีความเชื่อมั่นเพิ่มมากขึ้น

4. ความเสี่ยงที่จะเกิดความล้มเหลวลดลง

ข้อเสีย

1. หา Component ที่ตรงตามความต้องการได้ยาก

2. ยากในการปรับปรุง Component ให้ตรงตามความต้องการ

4. Process Iteration

การพัฒนาแบบวนซ้ำๆ (loop) มี 2 วิธี

1. Increment delivery การส่งระบบเพิ่มเติมไปเรื่อยๆ ทีละชุดจนเสร็จ

2. Spiral delivery พัฒนาแบบก้หอย

4.1 Increment delivery

ประโยชน์

1. ลูกค้าได้รับประโยชน์ในการส่งมอบเร็วขึ้น คือการที่ลูกค้าสามารถนำระบบบางส่วนไปใช้งานได้

2. ลดความเสี่ยงที่โครงการจะล่ม

3. ฟังก์ชันที่มีความเสี่ยงจะถูกทดสอบมากที่สุด ทำให้เกิดความผิดพลาดได้น้อย

4.2 Spiral delivery

เป็นการพัฒนาหนุมเป็นรอบๆ เป็นเกียววนคล้ายก้นหอย แบ่งออกเป็น 4 ส่วน

1. กำหนดวัตถุประสงค์และความสำคัญ

2. ประเมินความเสี่ยง

3. พัฒนา และตรวจสอบความต้องการ

4. วางแผน

Process Activity

Process Activity คือ กิจกรรมขั้นตอนการจัดทำ Software

1. Software Specification

2. Software Design and implementation

3. Software validation

4. Software evolution

ขั้นตอนที่ 1 Software Specification กระบวนกำหนดความต้องการ

คือ กระบวนการวิศวกรรมความต้องการ ซึ่งก็คือการกำหนดความเป็นไปได้ให้กับระบบ

Requirements engineering process

1. Feasibility Study ศึกษาความเป็นไปได้ เช่น งบประมาณ เวลา Software Hardware

2. Requirement elicitation and analysis สกัดความต้องการ เพื่อให้รู้ว่าความต้องการของระบบ

มีอะไรบ้าง

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

4. Requirement validation ขั้นการตรวจสอบว่าตรงจามความต้องการหรือไม่

ขั้นตอนที่ 2 Software design and implementation

Design เป็นขั้นตอนการออกแบบและเขียนโปรแกรม

Implementation การนำไปใช้งาน

Debugging process แบบจำลองการแก้่ไขโปรแกรม

1. หาตำแหน่งที่ผิดพลาดของโปรแกรม

2. ออกแบบว่าจะแก้ไข ข้อผิดพลาดที่เกิดขึ้นอย่างไร

3. ซ่อมบำรุง ทำการแก้ไข

4. ทดสอบการแก้ไข ว่าถูกต้องและผ่านหรือไม่

ขั้นตอนที่ 3 Software validation การทดสอบซอฟต์แวร์

Verification ทดสอบว่าซอฟต์แวร์ที่พัฒนาขึ้นตรงกัยความต้องการหรือไม่ โปรแกรมเมอร์ทดสอบ

Validation ทดสอบว่าตรงกับความต้องการของลูกค้าหรือไม่

Testing Process

1. Component or unit testing การทดสอบทีละส่วน ทีละระบบ

2. System testing การทดสอบทั้งระบบรวมกัน

3. Acceptance testing การทดสอบเพื่อการยอมรับ จากผู้ใช้งานจริง และใช้ข้อมูลจริง

ขั้นตอนที่ 4 Software evolution ขั้นตอนในการเปลี่ยนแปลงโปรแกรมตามความต้องการของ User

เป็นขั้นตอนการปรับปรุงโปรแกรมให้ทันยุคทันสมัย

The Rational Unified Process คือ คอมพิวเตอร์ที่ช่วยในการสร้างซอฟต์แวร์ RUP เขียนอยู่บน UML

การเขียนโปรแกรมแบบ UML มี 3 มุมมอง

1. แสดงขั้นตอนการทำงานให้เห็นเป็นขั้นๆ

2. แสดงให้เห็นกิจกรรมว่ามีอะไรบ้าง

3. แสดงให้เห็นถึงการปฎิบัติงานที่ดี

RUP phase model แบ่งออกเป็น 4 ขั้นตอน ***แต่ละขั้นมีการทำซ้ำบ่อยครั้ง

***สถาปัตยกรรม มีจุดเด่น คือ การค้นหาความเสี่ยงและวิเคราะความเสี่ยง

1. Inception ระยะเริ่มต้นของการดำเนินงาน กำหนดขอบเขตหน้าที่หลักของระบบ

2. Elaboration ทำความเข้าใจระบบ

3. Construction ออกแบบ เขียน ทดสอบ โดยแบ่งออกเป็นส่วนๆ โดยให้ Programmer ช่วยกัน

เขียน แล้วค่อยนำมารวมกัน หลังจากนั้นจะได้ ซอฟต์แวร์ และ เอกสารของซอฟต์แวร์

ข้อปฎิบัติการใช้ RUP

1. พัฒนาโปรแกรมแบบซ้ำๆ หากไม่สมบรูณ์ให้กลับไปทำใหม่

2. บริหารความต้องการให้ดีว่า ความต้องการไหนมีความสำคัญกว่า

3. ควรใช้งาน Component ที่มีอยู่แล้ว

4. ยึด Model RUP มาช่วยในการออกแบบ

5. ตรวจสอบคุณภาพของซอฟต์แวร์ให้ดีอยู่เสมอ

6. ควบคุมการเปลี่ยนแปลงของซอฟต์แวร์ให้น้อยที่สุด