Software Engineering

วันพฤหัสบดีที่ 18 ตุลาคม พ.ศ. 2555

SRS

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

Use Case Diagram

Sequence Diagram

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

สรุปบทที่ 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

สรุปบทที่ 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

สรุปบทที่ 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

สรุปบทที่ 6

Requirements engineering processes

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

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

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

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

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

Feasibility studies

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

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

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

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

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

Feasibility study implementation

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

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

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

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

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

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

Problems of requirements analysis

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

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

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

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

Process activities

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

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

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

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

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

7. ทำเอกสาร

ATM stakeholders

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

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

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

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

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

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

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

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

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

Interviewing

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

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

วันอาทิตย์ที่ 16 กันยายน พ.ศ. 2555

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