Transcript 290355 Software Engineering

290355 Software Engineering
บทที่ 5
การออกแบบซอฟต์ แวร์ (2)
อ.ธารารัตน์ พวงสุ วรรณ
คณะวิทยาศาสตร์ และศิลปศาสตร์
มหาวิทยาลัยบูรพา วิทยาเขตสารสนเทศจันทบุรี
เนือ้ หา







การออกแบบส่ วนต่อประสาน (Interface Design)
กระบวนการในการพัฒนาส่ วนต่อประสาน
รู ปแบบของส่ วนต่อประสานกับผูใ้ ช้ (User Interface)
การประเมินส่ วนต่อประสาน
เกณฑ์คุณภาพ
การวิเคราะห์และประเมินคุณภาพงานออกแบบซอฟต์แวร์
การวัดการออกแบบซอฟต์แวร์
การออกแบบส่ วนต่ อประสาน
การออกแบบส่วนต่อประสานมีอยู่ 3 เรือ่ ง คือ
 การออกแบบส่วนต่อประสานระหว่างองค์ประกอบย่อยภายในซอฟต์แวร์
 การออกแบบส่วนต่อประสานระหว่างซอฟต์แวร์และองค์ประกอบอื่นๆ ที่
ไม่ใช่มนุษย์ทเ่ี ป็ นส่วนผลิต และใช้ขอ้ มูล
 การออกแบบส่วนต่อประสานระหว่างมนุ ษย์กบ
ั คอมพิวเตอร์
Interface Design
Easy to learn?
Easy to use?
Easy to understand?
Interface Design
Theo Mandel ได้บญ
ั ญัตกิ ฎ 3 ข้อในการออกแบบส่วนต่อประสาน คือ
 ให้ผใู้ ช้เป็ นผูค
้ วบคุมการทางาน - Place the user in control
 ลดภาระการต้องจดจาของผูใ้ ช้ - Reduce the user’s memory load
 สร้างส่วนต่อประสานอย่างคงเส้นคงวา (สอดคล้องกัน) - Make the
interface consistent
ให้ผใ้ ู ช้เป็ นผูค้ วบคุมการทางาน
การออกแบบควรคาถึงลูกค้า (ความต้องการของผูใ้ ช้) ควรปล่อยให้ผใู้ ช้ม ี
อิสระในการเลือกใช้งานหรือโต้ตอบกับระบบ และสามารถควบคุมการใช้
งานบางส่วนได้
 มีหลักเกณฑ์ในการออกแบบทีใ่ ช้ผใู้ ช้ควบคุมดังนี้
1. กาหนดโหมดการโต้ตอบในลักษณะที่ไม่บงั คับผูใ้ ช้โดยไม่จาเป็ น
หรือในทางที่ผใู้ ช้ไม่ต้องการที่จะทา เช่น ส่วนตรวจสอบคาสะกดใน
โปรแกรม ไม่ควรบังคับให้ผใู้ ช้เข้าสูโ่ หมดการตรวจสอบคาทันทีทพ่ี บ
คาผิด ควรให้ผใู้ ช้ไปแก้ไขเองเมือ่ ต้องการ และเป็ นการแก้ไขที่ใช้งานได้
ง่ายด้วย

ให้ผใ้ ู ช้เป็ นผูค้ วบคุมการทางาน
2.
3.
4.
จัดให้มีการโต้ตอบที่ยืดหยุ่น สามารถโต้ตอบกับระบบได้มากกว่า 1
ทาง เนื่องจากผูใ้ ช้แต่ละคนมีความชอบทีแ่ ตกต่างกัน จึงต้องมีตวั เลือกให้ใช้
โปรแกรมผ่าน คียบ์ อร์ด เมาส์ ปากกา หรือเสียง เพือ่ สังงานระบบได้
่
อนุญาตให้ผใ้ ู ช้ทาการหยุดหรือสามารถยกเลิกได้ เช่น ผูใ้ ช้ควรจะ
สามารถสลับการทางานไปยังโปรแกรมอื่น โดยไม่สง่ ผลกระทบกับข้อมูลทีท่ า
ไป
ออกแบบให้การโต้ตอบเป็ นไปตามระดับความชานาญในการใช้งาน
เตรียมเครื่องมือสร้างการทางานแบบอัตโนมัติให้กบั ผูใ้ ช้ เนื่องจากผูใ้ ช้
มีทกั ษะในการใช้งานไม่เหมือนกันจึงควรปรับเปลีย่ นส่วนต่อประสารให้
เหมาะกับความต้องการเฉพาะตัวได้ บ่อยครัง้ ทีผ่ ใั ้ ช้ตอ้ งทางานทีซ่ ้าเดิม จึง
ควรมีกลไกแมคโคร (marco) ทีช่ ว่ ยให้ผใู้ ช้สะดวกในการทางาน
ให้ผใ้ ู ช้เป็ นผูค้ วบคุมการทางาน
5. ซ่อนรายละเอียดด้านเทคนิคจากผูใ้ ช้ทวไป
ั ่ ไม่ควรให้ผใู้ ช้
ติดต่อกับระบบปฏิบตั ิ การด้วยการพิมพ์คาสังโดยตรง
่
แต่หาก
จาเป็ นควรสร้างเป็ น wizard ให้ผใู้ ช้ตดิ ต่อกับระบบปฏิบตั กิ าร หรือ
การจัดการแฟ้มข้อมูล
6. การออกแบบวัตถุที่วางไว้บนจอให้เข้าถึงโดยตรง เพือ่ ผูใ้ ช้จะ
รูส้ กึ ว่าได้ควบคุมวัตถุทด่ี ไู ด้ เช่นการใช้เครือ่ งมือยืดขนาดใน
โปรแกรม photoshop ผูใ้ ช้จะสามารถเข้าใจได้ทนั ที
ลดภาระการต้องจดจาของผูใ้ ช้


ซอฟต์แวร์ทใ่ี ห้ผใู้ ช้จดจารายละเอียดการทางานมากเกินไป เสีย่ งต่อการ
เกิดความผิดพลาดในการใช้งานสูง จึงไม่ควรเพิม่ ภาระให้ผใู้ ช้งานต้อง
จดจา ระบบควรสามารถจดจาข้อมูลทีไ่ ม่เปลีย่ นแปลงบ่อย และช่วยเตือน
ความจาให้ผใู้ ช้เมือ่ ต้องกลับมาใช้งานภายหลังได้
Mandel ออกแบบหลักการทีช่ ว่ ยลดภาระการจดจาของผูใ้ ช้ดงั นี้
ลดภาระการต้องจดจาของผูใ้ ช้
1. ลดความต้องการใช้งานหน่ วยความจาระยะสัน้ ของผูใ้ ช้ ขณะที่
ใช้โปรแกรมอยู่ ส่วนต่อประสานควรจะออกแบบให้ลดความ
จาเป็ นทีต่ อ้ งจดจาการกระทาและผลทีเ่ พิง่ ทามา เพือ่ ให้ผใู้ ช้สามารถ
ตรวจสอบงานทีท่ าได้โดยไม่ตอ้ งเสียเวลานึกย้อนกลับไปด้วยตนเอง
2. การกาหนดค่าโดยปริยายที่มีความหมาย ควรกาหนดค่าเริม่ ต้น
การใช้งานทีเ่ หมาะสมกับผูใ้ ช้ทวไป
ั ่ และมีตวั เลือกอื่นเพือ่ ใช้ผใู้ ช้
สามารถปรับแต่งค่าได้ และสามารถเรียกคืนค่าเริม่ ต้นกลับมาได้
ด้วย
ลดภาระการต้องจดจาของผูใ้ ช้
3.
4.
5.
นิยามปุ่ มลัด (shortcut) ที่เข้าใจง่าย ตัวย่อควรผูก้ บั การกระทาในลักษณะ
ทีง่ า่ ยต่อการจดจา เช่น ปุม่ Ctrl+S แทนคาสังการบั
่
นทึกข้อมูล โดยทัวไปมั
่ ก
ใช้อกั ษรตัวแรกของชื่อเรียกคาสัง่
การจัดภาพของส่วนต่อประสานควรเป็ นไปตามอุปลักษณ์ ของโลกจริง
เพือ่ ให้ผใู้ ช้เข้าใจลาดับการทางานได้งา่ ย โดยไม่ตอ้ งจดจาขัน้ ตอนการโต้ตอบ
กับระบบ
เปิดเผยข่าวสารในลักษณะค่อยๆ เพิ่มพูน ส่วนต่อประสานควรมีการ
จัดลาดับชัน้ แสดงรายละเอียดการใช้งาน เช่นแสดงรายละเอียดพอสังเขป
ก่อน ส่วนรายละเอียดอื่นๆ ให้ผใู้ ช้คลิกเลือกได้เองเมือ่ ต้องการ เช่น การขีด
เส้นใต้ มีหลายรูปแบบจะไม่ถูกแสดงในเบือ้ งต้น เมือ่ ผูใ้ ช้เลือกเมนูขดี เส้นใต้
จึงค่อยแสดงรายละเอียด เช่น เส้นเดีย่ ว เส้นคู่ เส้นประ เป็ นต้น
สร้างส่วนต่อประสานอย่างคงเส้นคงวา
(สอดคล้องกัน)

ส่วนประสานควรรับและแสดงผลในลักษณะคงเส้นคงวา หมายถึง
 ข่าวสารทางภาพจัดระเบียบตามมาตรฐานการออกแบบเดียวกันตลอด
ทุกหน้าจอของระบบ
 กลไกการท่องระบบจากงานหนึ่งสูง่ านหนึ่งเป็ นไปอย่างคงเส้นคงวา
สอดคล้องกัน เชือ่ มโยงกันเป็ นลาดับขัน้ ตอน

หลักการออกแบบทีช่ ว่ ยให้สว่ นต่อประสานคงเส้นคงวา มีดงั นี้
สร้างส่วนต่อประสานอย่างคงเส้นคงวา
(สอดคล้องกัน)
1.
2.
ช่วยให้ผใ้ ู ช้ทราบว่างานปัจจุบนั อยู่ภายใต้บริบทใด ระบบอาจมีหลาย
หน้าจอซึง่ อาจทาให้ผใู้ ช้สบั สนว่าทางานอยูใ่ นขัน้ ตอนใด จึงต้องมีสว่ นทีบ่ ่ง
บอก เช่น ชื่อหน้า ไอคอน สี ทีช่ ว่ ยให้ผใู้ ช้ทราบว่าปจั จุบนั คืออะไร มาจาก
ส่วนงานไป และจะไปต่อได้อย่างไรบ้าง
ดารงความคงเส้นคงวาตลอดทัง้ ตระกูลของแอพพลิเคชัน่ นันคื
่ อ ส่วน
ประสานต้องเหมือนและสอดคล้องกันตลอดกลุ่มผลิตภัณฑ์เดียวกัน แม้วา่
วัตถุประสงค์ของแต่ละโปรแกรมจะแตกต่างกันก็ตาม เช่น โปรแกรม word,
excel, access ซึง่ ผลิตในกลุม่ ผลิตภัณฑ์เดียวกัน จะมีสว่ นต่อประสานที่
คล้ายกัน
สร้างส่วนต่อประสานอย่างคงเส้นคงวา
(สอดคล้องกัน)
3. ถ้ารูปแบบการโต้ตอบที่ผา่ นมาทาให้ผใ้ ู ช้เกิดความคาดหมาย อย่าเปลี่ยน
กฎนัน้ ยกเว้นมีเหตุผลสมควร นันคื
่ อ ไม่ควรเปลีย่ นลักษณะการโต้ตอบที่
โปรแกรมส่วนใหญ่ใช้ เพราะผูใ้ ช้จะคุน้ เคยกับการโต้ตอบในลักษณะนัน้ เช่น
Ctrl+S เป็ นการบันทึกข้อมูล ถ้าเราเปลีย่ น Ctrl+S เป็ นการทางานอย่างอื่น ผูใ้ ช้
จะสับสนได้
การวิเคราะห์ และออกแบบส่ วนประสานกับผู้ใช้
แบบจาลองการวิเคราะห์และออกแบบส่วนต่อประสาน มี 4 แบบจาลอง คือ
 User model — แบบจาลองผูใ้ ช้ (บอกลักษณะของผูใ้ ช้งานในระบบ ว่ามีผใู้ ช้
แบบใดบ้าง)
 Design model — แบบจาลองการออกแบบ (การออกแบบทีค
่ านึงถึงผูใ้ ช้งาน
กาหนดลักษณะการโต้ตอบในการใช้งานระบบ)
 Mental model (system perception) — แบบจาลองสภาพจิตของผูใ้ ช้ หรือ
การรับรูร้ ะบบ (ภาพลักษณ์ของระบบทีผ่ ใู้ ช้จนิ ตนาการไว้ ขึน้ อยู่กบั ภูมหิ ลัง
ของผูใ้ ช้)
 Implementation model — แบบจาลองอิมพลีเมนต์เทชัน่ (“look and feel”
หน้าตาของส่วนประสาน เข้ากับการสนับสนุนข้อมูล)
กระบวนการในการพัฒนาส่ วนต่ อประสาน
กระบวนการในการพัฒนาส่วนต่อประสาน เป็ นกระบวนการวนซ้าทีแ่ ทนได้
เป็ นแบบจาลองเกลียว
1. การวิเคราะห์และสร้างแบบจาลอง
2. การออกแบบส่วนต่อประสาน
3. การอิมพลีเมนต์สว่ นต่อประสาน
4. การประเมินส่วนต่อประสาน

การวิเคราะห์ส่วนต่อประสาน (Interface
Analysis)
Interface analysis means understanding
 ในการวิเคราะห์สว
่ นต่อประสาน ต้องเข้าใจปญั หาก่อน นันคื
่ อ
 the people -- เข้าใจคน บุคลากรทีใ่ ช้งานระบบ
 the tasks -- เข้าใจงานทีผ
่ ใู้ ช้ตอ้ งการใช้เพือ่ ให้ทางานให้สาเร็จ
 the content -- เข้าใจเนื้อหาทีจ
่ ะต้องนาเสนอในส่วนต่อประสาน
 the environment -- เข้าใจสิง่ แวดล้อมทีง่ านเหล่านัน
้ ทางานอยู่

การวิเคราะห์ผใ้ ู ช้งาน (User Analysis)


ผูใ้ ช้แต่ละคนมีภาพลักษณ์ของระบบภายในใจ การเข้าใจระบบก็จะขึน้ อยู่
กับภาพลักษณ์ทม่ี ี ในทางการออกแบบจึงควรเข้าใจผูใ้ ช้วา่ จะใช้ระบบ
อย่างไร ต้องการส่วนต่อประสานในลักษณะใด
การสัมภาษณ์เป็ นวิธที จ่ี ะทาความเข้าใจความต้องการของผูใ้ ช้งาน ซึง่ จะ
ช่วยให้นกั ออกแบบเข้าใจว่า ใครคือผูใ้ ช้งาน จะแบ่งกลุม่ ผูใ้ ช้อย่างไร ผูใ้ ช้
แต่ละกลุม่ มีทกั ษะและประสบการณ์ในระดับใด แบบจาลองสภาพจิตใจ
ของผูใ้ ช้ทม่ี ตี ่อระบบเป็ นอย่างไร และส่วนต่อประสานจะตอบสนองความ
ต้องการของผูใ้ ช้ได้อย่างไร
การจาลองและวิเคราะห์ งานย่ อย

Answers the following questions …
 What work will the user perform in specific circumstances? (ลักษณะ
ของการปฏิบตั งิ าน)
 What tasks and subtasks will be performed as the user does the
work? (งานหลักและงานย่อยทีต่ อ้ งปฏิบตั )ิ
 What specific problem domain objects will the user manipulate as
work is performed? (ปญั หาหลักทีต่ อ้ งใช้งานเพือ่ ทางาน ระบบงานและ
ส่วนทีเ่ กีย่ วข้อง)
 What is the sequence of work tasks—the workflow? (ลาดับของงานที่
ทา)
 What is the hierarchy of tasks? (ลาดับชัน
้ ของงานย่อย)
การจาลองและวิเคราะห์ งานย่ อย
เทคนิคในการวิเคราะห์ออกแบบส่วนต่อประสาน
 Use-cases define basic interaction
 Task elaboration refines interactive tasks
 Object elaboration identifies interface objects (classes)
 Workflow analysis defines how a work process is completed when
several people (and roles) are involved
pat ient
ตัวอย่ าง
r e q u e st s t h at a
p r e scr ip t io n b e r e f ille d
pharmacist
d e t e r m in e s st at u s o f
p r e scr ip t io n
no refills
remaining



แผนภาพ กระบวนการทางานเมือ่ ผูป้ ว่ ย
ขอให้เติมยาทีห่ มด
มีผเู้ กีย่ วข้อง 3 ส่วน patient, pharmacist,
physician
นักออกแบบส่วนต่อประสานควรคานึงถึง
ลักษณะของผูใ้ ช้ และกิจกรรมงาน
physician
refills
remaining
ch e cks in v e n t o r y f o r
r e f ill o r alt e r n at iv e
ch e cks p at ie n t
r e co r d s
approves refill
refill not
allowed
e v alu at e s alt e r n at iv e
m e d icat io n
r e ce iv e s o u t o f st o ck
n o t if icat io n
out of stock
alternative
available
in stock
r e ce iv e s t im e / d at e
none
t o p ick u p
p icks u p
p r e scr ip t io n
f ills
p r e scr ip t io n
r e ce iv e s r e q u e st t o
co n t act p h y sician
Figure 12.2 Swimlane diagram for prescript ion refill funct ion
การวิเคราะห์ การนาเสนอเนือ้ หา


เนื้อหาทีน่ าเสนอ : รายงานทีเ่ ป็ นตัวอักษร รูปภาพ หรือข้อมูลเฉพาะ เช่น เสียง
หรือภาพเคลื่อนไหว
 ถูกสร้างโดยส่วนประกอบของระบบทีไ่ ม่เกีย
่ วข้องกับส่วนต่อประสาน
 ดึงมาจากข้อมูลทีเ่ ก็บในฐานข้อมูล
 ส่งมาจากระบบภายนอก
การวิเคราะห์การนาเสนอเนื้อหา ทาให้ทราบถึงเอกสารทีต่ อ้ งการและการ
แสดงผลทีต่ อ้ งการ รูปแบบและความสวยงามของเนื้อหาจะถูกพิจารณา
การวิเคราะห์ สิ่งแวดล้ อมการทางาน


นักออกแบบควรคานึงถึงสภาพแวดล้อมทีใ่ ช้งานของระบบ ข้อจากัดทาง
กายภาพทีอ่ าจเป็ นอุปสรรคในการใช้งาน เช่น ในโรงงานเสียงอาจจะดัง
การใช้ลาโพงอาจไม่เหมาะสม หรือการใช้เมาส์ คียบ์ อร์ดในพืน้ ที่คบั แคบ
อาจทาให้การทางานลาบาก
วัฒนธรรมในการทางาน เช่น ข้อมูลต้องได้รบั การรับรองจากหลายฝา่ ย
ก่อนบันทึกหรือไม่ ผูใ้ ช้งานจะได้รบั ความช่วยเหลือจากระบบอย่างไร นัก
ออกแบบต้องตอบคาถามเหล่านี้ก่อนการออกแบบเสร็จสิน้ และควรเพิม่
ส่วนต่อประสานทีจ่ ะอานวยความสะดวกด้วย
ขั้นตอนการออกแบบส่ วนต่ อประสาน




Define interface objects and actions (operations) – นิยามวัตถุและ
ตัวดาเนินการ โดยใช้ขอ้ มูลจากการวิเคราะห์
Define events (user actions) -- กาหนดเหตุการณ์ทเ่ี ป็ นการกระทา
ของผูใ้ ช้
Depict each interface state -- แสดงด้วยรูปถึงสถานะของส่วนต่อ
ประสานทีผ่ ใู้ ช้จะได้สมั ผัส
Indicate how the user interprets the state of the system – อธิบาย
ให้ทราบความหมายของข้อมูลทีแ่ สดง ระบุวา่ ผูใ้ ช้จะเข้าใจสถานะของ
ระบบอย่างไร
Design Issues
ข้อควรคานึงในการออกแบบ
 Response time
: เวลาในการตอบสนองของระบบ
 Help facilities
: การช่วยเหลือแก่ผใู้ ช้งาน
 Error handling
: การจัดการความผิดพลาด
 Menu and command labeling : การกาหนดชือ
่ คาสังและเมนู
่
 Application accessibility
: การเข้าถึงระบบงาน
 Internationalization
: ความเป็ นสากล
รูปแบบของ User Interfaces



เพือ่ ให้ผใู้ ช้งานสามารถโต้ตอบกับระบบอย่างมีประสิทธิภาพ
นิยมใช้แบบกราฟิก (Graphic User Interface :GUI)
มีรปู แบบดังนี้ คือ
 การโต้ตอบด้วยคาสัง่ (Command Language Interaction)
 การโต้ตอบด้วยเมนูคาสัง่ (Menu Interaction)
 การโต้ตอบด้วยแบบฟอร์ม (Form Interaction)
 การโต้ตอบด้วยการทางานเชิงวัตถุ (Object-Based Interaction)
 การโต้ตอบด้วยภาษามนุ ษย์ (Natural Language Interaction)
การโต้ตอบด้วยคาสัง่ (Command Language
Interaction)




คาสัง่ copy ไฟล์จาก drive c: ไปยัง drive a:
C:\copy ex1.doc a:ex1.doc
เป็ นการโต้ตอบกับระบบโดยทีผ่ ใู้ ช้
จะต้องพิมพ์คาสังลงในช่
่
องป้อนคาสัง่
เพือ่ กระตุน้ ให้เกิดการทางานในระบบ
ผูใ้ ช้จะต้องจาคาสัง่ ไวยากรณ์ และ
กฎเกณฑ์ต่างๆ
เช่น ผูใ้ ช้ทช่ี านาญการใช้
ระบบปฏิบตั กิ าร DOS
ลดความนิยมในปจั จุบนั
การโต้ตอบด้วยเมนูคาสัง่ (Menu Interaction)
เป็ นการโต้ตอบกับระบบด้วยการแสดงเมนูคาสัง่ โดยผูใ้ ช้ไม่
จาเป็ นต้องป้อนคาสังเอง
่
 รูปแบบเมนูมด
ี งั นี้ คือ

 Pull-down
Menu
 Pop-up Menu
Pull-down Menu
Pull-down
Menu เมนูแสดง
คำสงั่ โดยแบ่ง
รำยกำรของคำสงั่ เป็ น
หมวดหมู่ เมือ
่ ผู ้ใช ้
คลิกจะแสดงรำยกำร
คำสงั่ จำกบนลงล่ำง
Pop-up Menu
Pop-up Menu
เมนูแสดงคำสงั่ เมือ
่
้ กเลือกวัตถุ
ผู ้ใชคลิ
หรือ object ใด ๆ ใน
จอภำพ คำสงั่ หรือ
คุณสมบัตท
ิ เี่ กีย
่ วข ้อง
กับ object นัน
้ จะถูก
แสดงออกมำ
หลักเกณฑ์ในการออกแบบเมนูคาสัง่
1.
2.
3.
4.
5.
6.
แต่ละเมนูคาสัง่ ควรเลือกใช้คาสัง่ ที่สื่อความหมายได้ชดั เจน
ควรมีการใช้ตวั อักษรพิมพ์ใหญ่หรื อตัวอักษรพิมพ์เล็กตามความ
เหมาะสม
ควรมีการจัดกลุ่มคาสัง่ ที่มีความเกี่ยวข้องกันไว้ในกลุ่มเดียวกัน
ไม่ควรมีจานวนเมนูคาสัง่ มากเกินไป
ไม่ควรมีเมนูยอ่ ยสาหรับเมนูคาสัง่ ที่มีการทางานย่อยภายในมากเกินไป
เมื่อมีการเลือกเมนูคาสัง่ ควรออกแบบให้มีแถบสี ปรากฏที่เมนูคาสัง่ ที่
ถูกเลือก
การโต้ตอบด้วยแบบฟอร์ม (Form Interaction)
เป็ นการโต้ตอบที่ผใู ้ ช้ระบบจะต้องป้ อนข้อมูลลงในช่องว่างที่อยูใ่ น
แบบฟอร์มที่แสดงหน้าจอคอมพิวเตอร์
 คล้ายการกรอกแบบฟอร์ มลงในกระดาษ
 ชื่อของช่องป้ อนข้อมูลต้องสื่ อความหมาย
 แบ่งส่ วนของข้อมูลบนฟอร์ มให้เหมาะสม
ั ช่องป้ อนข้อมูลที่ตอ้ งใช้ขอ้ มูลนันนบ่อยครันง
 ควรแสดงข้อมูลเริ่ มต้นให้กบ
 ช่องป้ อนข้อมูลไม่ควรยาวมากจนเกินไป

ตัวอย่ างการโต้ ตอบด้ วยแบบฟอร์ ม
การโต้ตอบเชิงวัตถุ (Object-Based Interaction)
เป็ นการโต้ตอบกับระบบที่ใช้สญ
ั ลักษณ์
 สัญลักษณ์เป็ นตัวแทนคาสัง่ ที่ใช้ในการปฏิบต
ั ิงาน
 สัญลักษณ์รูปภาพแทนคาสัง่ การทางานเรี ยกว่า ไอคอน (Icon)
 ประหยัดพืนนที่บนหน้าจอ

การโต้ตอบด้วยภาษามนุษย์ (Natural Language
Interaction)
 เป็ นการโต้ตอบกับระบบด้วยการใช้เสี ยงพูดของผูใ้ ช้ระบบ
 ใช้เสี ยงพูดทันงการนาข้อมูลเข้าและออกจากระบบ
การออกแบบลาดับการเชื่อมโยงจอภาพ


เป็ นการออกแบบลาดับของการแสดงส่วนติดต่อกับผูใ้ ช้ของโปรแกรม หรือ
ลาดับของการแสดงส่วน User Interface ทางหน้าจอคอมพิวเตอร์
แผนภาพแสดงลาดับการเชือ่ มโยงจอภาพ (Dialogues Diagram)
ประกอบไปด้วย 3 ส่วน คือ
 ส่วนบน:
เลขลาดับหน้าจอ
 ส่วนกลาง: ชื่อหน้าจอการทางาน
 ส่วนล่าง: เลขลาดับหน้าจอทีอ
่ า้ งอิงมา ต่อไป หรือ ย้อนกลับ
Dialogues Diagram

Dialogues Diagram เป็ นแผนภาพแสดงลาดับการเชื่อมโยงของ
จอภาพ
เลขลาดับหน้าจอ
ชือ่ หน้าจอการทางาน
เลขลาดับทีอ่ า้ งอิงมา
ตัวอย่ าง
สัญลักษณ ของ Dialogue Diagram มีรายละเอียดดังนี้
- Top ใช แสดงหมายเลขลาดับเพือ่ การอ างอิงจากหน าจออื่น
หมายเลขลาดับในส วนบนนี้จะต องไม ซ้ากัน
- Middle ใช แสดงชื่อหน าจอทางานหรือข อความแสดง
รายละเอียดการทางาน เพือ่ ให ทราบว าหน าจอหมายเลข
ดังกล่าวใช ทางานใด
- Bottom ใช แสดงหมายเลขของหน าจอทีอ่ างอิงมา
(เชื่อมโยง) คัน่ ด้วยเครือ่ งหมายจุลภาค ( , ) ตามด วยหมายเลขหน
าจอต่่อไปหรือหน าจอย อนกลับเมือ่ เสร็จสิน้ การทางานแล ว
การประเมินการออกแบบ

หลังจากสร้างต้นแบบแล้ว จะต้องมีการประเมินว่าเป็ นไปตามความ
ต้องการของผูใ้ ช้หรือไม่ โดยทีมงานต้องเก็บข้อมูลความคิดเห็นของผูใ้ ช้
เพือ่ นาไปปรับปรุงต้นแบบให้สมบูรณ์ทส่ี ดุ
การประเมินการออกแบบ
วงจรการประเมินส่วนต่อประสาน
 สร้างแบบจาลองการออกแบบ
 สร้างต้นแบบส่วนต่อประสาน
 ผูใ้ ช้ประเมินส่วนต่อประสาน
 ปรับปรุงการออกแบบตามความ
คิดเห็นของผูใ้ ช้งาน
 ออกแบบส่วนทีต
่ อ้ งทาการ
เปลีย่ นแปลง
 ต้นแบบตัวต่อไปจะถูกสร้างขึน
้
คุณภาพและการประเมินคุณภาพงานออกแบบซอฟต์ แวร์
เกณฑ์คณ
ุ ภาพ (Quality Attributes)





การทางานของโปรแกรม (Functionality) จะประเมินจากลักษณะ (Feature Set) และ
ความสามารถ (Capability) ของโปรแกรม นอกจากนี้ ยังประเมินจากหน้าทีท่ วไปของ
ั่
โปรแกรม และความปลอดภัยเมือ่ ต้องทางานรวมเป็ นระบบ
ความสามารถในการใช้งาน (Usability) พิจารณาจากผลตอบกลับจากการใช้งานของผูใ้ ช้
ไม่วา่ จะเป็ นการใช้งานง่าย และเรียนรูง้ า่ ย
ความน่ าเชื่อถือ (Reliability) วัดจากความถีแ่ ละความรุนแรงของความผิดพลาดทีเ่ กิดขึน้
ความถูกต้องของผลลัพธ์ทไ่ี ด้ เวลาเฉลีย่ ของความล้มเหลว (Mean-Time-To-Failure:MTTF)
ความสามารถในการกูค้ นื ระบบ และความสามารถในการคาดการณ์ได้ของโปรแกรม
ประสิทธิภาพ (Performance) วัดจากความเร็วของการประมวลผล ระยะเวลาตอบสนอง
ทรัพยากรทีใ่ ช้ ปริมาณทีท่ าได้ในช่วงเวลาหนึ่ง และประสิทธิผลในการทางาน
ความสามารถในการสนับสนุนการใช้งาน (Supportability) และความสามารถในการ
บารุงรักษา (Maintainability) พิจารณาจากความสามารถในการเพิม่ เติมส่วนการทางาน
ความสามารถในการแปลงการทางาน และการบริการ ยังพิจารณาจากความสามารถในการ
ทดสอบ การทางานข้ามระบบได้ และการจัดสภาพแวดล้อมของระบบด้วย
การวิเคราะห์ และประเมินคุณภาพ
(Quality Analysis and Evaluation)
เป็ นกิจกรรมที่ช่วยให้มนั่ ใจว่าซอฟต์แวร์ที่ถูกออกแบบไว้จะต้องมี
คุณภาพ โดยทีมงานสามารถใช้เครื่ องมือและเทคนิคต่างๆ ในการ
วิเคราะห์และประเมิน ซึ่งแบ่งตามกิจกรรมได้ดงั นีน
 ทบทวนงานออกแบบซอฟต์ แวร์
(Software Design Review)
เทคนิคที่ช่วยให้การทบทวนงานออกแบบมีประสิ ทธิภาพ ได้แก่
Group-Based Technique เป็ นเทคนิคในการตรวจสอบและปรับปรุ ง
คุณภาพของงานออกแบบ เช่น การทบทวนสถาปัตยกรรม
ซอฟต์แวร์ และการตรวจสอบอย่างละเอียด เป็ นต้น
*** การออกแบบควรนาเสนอด้านข้อมูล สถาปัตยกรรม ส่ วน
ประสาน และ คอมโพเน้นท์ที่ชดั เจน
การวิเคราะห์ และประเมินคุณภาพ
(Quality Analysis and Evaluation)
ผลที่ได้จากการวิเคราะห์
จะนาไปประเมินคุณภาพของงานออกแบบ เทคนิคที่ช่วยให้การ
วิเคราะห์มีประสิ ทธิภาพ เช่น Fault-tree Analysis, Auto-cross
Checking เป็ นต้น
 การจาลองสถานการณ์ และการสร้ างต้ นแบบ (Simulation and
Prototyping) เช่น การจาลองเหตุการณ์ประสิ ทธิภาพของ
ซอฟต์แวร์ และการสร้างต้นแบบซอฟต์แวร์เพื่อทดสอบความ
เป็ นไปได้ เป็ นต้น
 วิเคราะห์ งานออกแบบ (Static Analysis)
การวัด (Measure)
การวัดสามารถใช้กบั การประเมินหรื อการประมาณการ
คุณลักษณะบางอย่าง เช่น ขนาด โครงสร้าง หรื อคุณภาพ ของ
ซอฟต์แวร์ได้
แบ่งออกเป็ น 2 ประเภท ดังนีน
 การวัดการออกแบบเชิ งฟังก์ ชัน (Function-Oriented Measure)
 การวัดการออกแบบเชิ งวัตถุ (Object-Oriented Design Measure)