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

สรุปบทเรียนที่ 11 User Interface Design


สรุปบทเรียนที่ 11
User Interface Design

การออกแบบหน้าจอการทำงานของระบบหรือที่เรียกว่าส่วนติดต่อระหว่างผู้ใช้งานกับระบบนั้น นักวิศวกรรมซอฟต์แวร์จะต้องให้ความสำคัญในการพูดคุยกับผู้ใช้มากที่สุด เพื่อเก็บรวบรวมความต้องการ
The Design Process (กระบวนการออกแบบส่วนติดต่อกับผู้ใช้ User Interface)
        จากภาพกระบวนการทำงานมีทั้งหมด 6 ขั้นตอน ดังนี้
1. ขั้นตอนการเก็บรวบรวมความและวิเคราะห์ความต้องการจาก User ว่า User มีกิจกรรมใดที่ต้องทำบ้าง มีความต้องการอย่างไรบ้าง
2. สร้างตัวต้นแบบใน Prototype Paper แล้วนำตัวต้นแบบที่สร้างขึ้นไปตรวจสอบกับ User อีกครั้ง ว่าตรงกับความต้องการหรือไม่ (ในขั้นตอนนี้ Output ที่ได้ คือได้การออกแยยตัวต้นแบบ Design prototype) กรณีที่ไม่ตรงตามความต้องการหรือผู้ใช้มีความต้องการเพิ่มเติมจะต้องมีการวนกลับไปแก้ไขตัวตนแบบ
3. นำตัวต้นแบบที่ได้จากขั้นตอนที่ 2 ไปตรวจสอบกับ end user ว่าตรงตามความต้องการหรือไม่ กรณีที่ไม่ตรงตามความต้องการหรือผู้ใช้มีความต้องการเพิ่มเติมจะต้องมีการวนกลับไปแก้ไขตัวตนแบบ
4. เมื่อตัวตนแบบที่สร้างขึ้นบนกระดาษผ่านการตรวจสอบความต้องการจาก User และ End User แล้ว นำมาสร้างตัวตนแบบจริงๆ บนคอมพิวเตอร์ที่สามารถกดคลิกปุ่ม หรือกรอกข้อมูลต่างๆ ได้จริงๆ
5. นำตัวต้นแบบทีสร้างขึ้นไปประเมินกับ end user ในกรณีที่ Prototype ที่สร้างขึ้นไม่ตรงกับความต้องการหรือมีความต้องการบางอย่างที่ end user จะต้องมีการวนกลับไปแก้ไขตัวตนแบบจนกว่า end user พอใจ ในขั้นตอนนี้ผลลัพธ์ที่ได้คือ Prototype จริงๆ ที่สามารถใช้งานได้จริงๆ ในสถานการณ์จริง กับลูกค้าจริง
6. นำ Prototype มาสร้างเป็น User Interface

Usability attributes หลักในการประเมิน User interface
1. Learnability สามารถเรียนรู้ได้ง่าย เช่น User ที่ไม่เคยรู้จักการใช้งานระบบมาก่อนสามารถเรียนรู้การใช้งานได้ง่าย
2. Speed of operation ความรวดเร็วในการทำงานของระบบ เช่น ระบบที่สร้างขึ้นมีความรวดเร็วมีความรวดเร็วในการประมวลผล ในการตอบสนองต่อการใช้งานของผู้ใช้
3. Robustness ความทนทานในการใช้งาน เช่นความทนทานของระบบเมื่อผู้ใช้งานกรอกข้อมูลผิดพลาด ระบบจะมีการแจ้งเตือนอย่างไร
4. Recoverability ความสามารถในการกู้คืน เช่น เมื่อระบบเกิดความล้มเหลวในการทำงาน ระบบสามารถกู้คืนการทำงานที่เป็นสถานะปกติโยใช้เวลาเท่าไร
5. Adaptability ความสามารถในการใช้งาน คือ ในเรื่องของประสิทธิภาพการใช้งานระบบ

Simple evaluation techniques (เทคนิคในการประเมิน User interface)
1. สร้างแบบสอบถามให้ User กรอกข้อมูลแล้วนำมาประมวลผล
2. ใช้การบันทึก Video บันทึกภาพขณะที่ผู้ใช้งาน ทดลองใช้งานระบบ แล้วดูปฏิกิริยาตอบสนองตอนใช้งาน
3. เขียนโปรแกรมให้ทำหน้าที่เก็บข้อมูลว่า User ได้ทำอะไรกับระบบบ้าง เพื่อดูการกระทำของ User เพื่อใช้ในการประเมิน
4. เพิ่มปุ่มให้ User กรอกข้อมูลในหน้านั้นเลยว่า User มีความรู้สึกอย่างไรกับระบบ


สรุปบทเรียนที่ 4 Software Project Management


สรุปบทเรียนที่ 4
Project Manager

สิ่งที่ Project Manager ต้องทำมี 6 อย่าง 
         1. เขียน Proposal ว่าระบบที่จะพัฒนาจะมีคุณสมบัติอย่างไร ทำประโยชน์อะไรให้องค์กรได้บ้าง เอามาใช้แก้ไขปัญหาอะไรและศึกษาความคุ่มค่าในการพัฒนา 
         2. เขียนแผนในการพัฒนา
         3. ประเมินต้นทุนในการพัฒนา 
         4. ติดตามดูการพัฒนา ว่าตรงตามที่กำหนดไว้หรือไม่ ตรงกับความต้องการไหน 
         5. คัดเลือกบุคลากร เข้าทีมพัฒนา จัดสรรตำแหน่งและประเมินความสามารถ 
         6. นำเสนอรายงานในทุกๆ ช่วงของ Milestone

2 เรื่องสำคัญที่ Project manager ต้องดูแล
              1. Project staffing เรื่องของการบริหารจัดการบุคลากร
1.1 จัดหาบุคลากรที่เหมาะสม
1.2 หมอบหมายงานที่เหมาะสม
1.3 พัฒนาบุคลากร
              2.  Project planning สำคัญที่สุดและใช้เวลามากที่สุด จะต้องมีการวางแผนตั้งแต่เริ่มจนจบ มักจะมีการเปลี่ยนแปลงตลอด

โครงสร้างการวางแผนโครงการ 
         1. Project organization กำหนดลักษณะโครงสร้างของโครงการ
                2.Risk analysis มีการวิเคราะห์ความเสี่ยง 
                3. Hardware and software requirement วิเคราะห์ความต้องการทั้งหมดในแง่ของ hardware software 
                4. Work breakdown แตกงานออกเป็นงานย่อยๆ 
                5. Monitoring and reporting machines ติดตามดูการพัฒนา


Risk management process 
         1. Risk Identification บอกให้ได้ว่าอะไรบ้างคือความเสี่ยง 
         2. Risk Analysis วิเคราะห์ความเสี่ยง ความเป็นไปได้ที่จะเกิดขึ้น 
         3. Risk Planning วางแผนควบคุมความเสี่ยง 
         4. Risk Monitoring ติดตามดูความเสี่ยง

วันพุธที่ 3 ตุลาคม พ.ศ. 2555

สรุปบทเรียนที่ 6 Requirements Engineering


สรุปบทเรียนที่ 6
System Requirement
วิศวกรรมความต้องการ

กระบวนการวิศวกรรมความต้องการ แบ่งออกเป็น 4 ขั้นตอน คือ
           1. ศึกษาความเป็นไปได้
เป็นขั้นตอนการศึกษาเพื่อตัดสินใจว่ามีความคุ้มค่าในการลงทุนหรือไม่
- ตรงกับวัตถุประสงค์ขององค์กรหรือไม่
- เทคโนโลยีในปัจจุบันสามารถนำมาพัฒนาระบบได้หรือไม่ สามารถทำได้ไหม
- ระบบใหม่สามารถทำงานร่วมกับระบบเก่าได้หรือไม่
ในการศึกษาความเป็นไปได้จะทำให้
1. ถ้าไม่พัฒนาระบบจะเกิดอะไรขึ้น
2. ปัญหาที่พบมีอะไรบ้าง
3. ระบบใหม่สามารถช่วยในการแก้ไขปัญหาได้อย่างไร
4. ต้องใช้เทคโนโลยีอะไรและใช้ความสามารถพิเศษอะไรบ้าง
           2. ค้นหาและวิเคราะห์ความต้องการ
                  ในขั้นตอนนี้เพื่อนำความต้องการที่ได้ไปสร้างเป็นแบบจำรอง ในการค้นหาและวิเคราะห์ความต้องการ เราต้องส่ง
                  เจ้าหน้าที่เข้าไปทำงานร่วมกับลูกค้าเพื่อค้นหาว่าในการทำงานของ User มีความต้องการอย่างไร มีขั้นตอนอย่างไร 
                  นอกจากนี้เรายังต้องสอบถามความต้องการจากผู้เกี่ยวข้องคนอื่นๆด้วย
           3. กำหนดความต้องการ
                  นำความต้องการที่ได้มาทำการวิเคราะห์แล้วทำการกำหนดเป็นความต้องการของ User และ System ทำให้ในขั้น
                  ตอนนี้เราได้ความต้องการของ user และ system
           4. ตรวจสอบความต้องการ
                  ตรวจสอบความต้องการที่ได้ เพื่อลดความผิดพลาดหรือปัญหาที่จะเกิดขึ้น ความต้องการที่ทับซ้อนกัน ความต้องการ
                  ที่มากเกินต้นทุนที่กำหนดไว้ เมื่อสิ้นสุดการตรวจสอบเราจะได้เอกสารความต้องการที่ถูกต้อง

รูปแบบในการตรวจสอบ
         1. ตรวจสอบความเที่ยงตรงจากตัวแทนผู้ใช้
         2. ความสมบูรณ์ของความต้องการ
         3. ความเป็นไปได้ของความต้องการทางด้าน เทคโนโลยี
         4. สามารถพิสูจน์ได้ เช่น ทำให้ลูกค้าเห็นได้ Prototype

ปัญหาในการวิเคราะห์ความต้องการ
                1. Stakeholder ไม่มีความรู้ความเข้าใจ
                2. Stakeholder อธิบายความต้องการด้วยศัพท์ทางเทคนิคที่เขาเข้าใจ และเราไม่เข้าใจ อาจทำให้เกิดการเข้าใจผิดได้
                3. Stakeholder มีความต้องการที่แตกต่างกัน เราต้องแบ่งกลุ่มความต้องการเพื่อไม่ให้ขัดแย้งกัน
                4. การเมืองและความขัดแย้งในองค์กร ส่งผลต่อระบบ อาจทำให้เกิดความผิดพลาดล้มเหลวในการพัฒนาได้
                5. มีการเปลี่ยนแปลงความต้องการระหว่างการพัฒนา เช่น SK คนใหม่เข้ามา ธุรกิจเปลี่ยน เปลี่ยนเทคโนโลยี

ทำไมต้องมีการปรับเปลี่ยนความต้องการ
1. ในระบบมีผู้ใช้หลายกลุ่ม เราต้องจัดลำดับความสำคัญของความต้องการ เพื่อไม่ให้เกิดความขัดแย้งใน SK
2.  งบประมาณไม่เพียงพอ
3.  สภาพแวดล้อม และ เทคโนโลยี เมื่อเกิดการเปลี่ยนแปลง ก็จะต้องมีการเปลี่ยนแปลงความต้องการให้มีความสอดคล้อง และ เหมาะสม

วันเสาร์ที่ 29 กันยายน พ.ศ. 2555

สรุปบทเรียนที่ 7 System Models


บทที่ 7 System Models 
การสร้างต้นแบบจำลองของ Software

เป็นขั้นตอนการนำความต้องการที่เก็บรวบรวมได้ มาสร้างเป็นแบบจำลอง (Model)

System Modeling การสร้างตัวต้นแบบ
    การสร้างตัวต้นแบบมีวัตถุประสงค์
         1. เพื่อให้เข้าใจว่าหน้าที่หลักของระบบทำงานอย่างไร ผู้ที่ควรจะต้องเข้าใจถึงกระบวนการคือ SA  
             เจ้าของระบบ User Programmer
         2. เพื่อให้สามารถอธิบายได้ว่าระบบเก่าและระบบใหม่มีความแตกต่างกันอย่างไร โดยแบ่งออกเป็น 
             3 มุมมองได้แก่
       1. มุมมองภาพรวมของระบบ
       2. มุมมองพฤติกรรมของระบบ
       3. มุมมองโครงสร้างของระบบ 

Model Types ประเภทของตัวต้นแบบ

                 1. Date processing model แบบจำลองแสดงการประมวลผลข้อมูล จะอธิบายพฤติกรรม       

                     ของระบบ

                 2. Composition model แบบจำลองอธิบายองค์ประกอบของ Entities

                 3. Architectural model อธิบายสถาปัตยกรรมของระบบ โดยจะแสดงให้เห็นถึงระบบย่อยภายใน

                     ด้วย

                 4. Classification model อธิบายการจัดแบ่งประเภทของ Entities

                 5. Stimulus/response model อธิบายตัวกระตุ่นหรือสิ่งกระตุ้น



Context Model
            แสดงขอบเขตของระบบ ว่ามีการเชื่อมโยงกับระบบอื่นๆ อย่างไร context models จะเน้นขอบเขตของระบบ ไม่เน้นรายระเอียดของระบบ
     ตัวอย่าง Context model ของระบบ ATM














            

               จาก Context Model ของระบบ ATM สามารถอธิบายได้ดังนี้ Model นี้ใช้แสดงขอบเขตการทำงานของระบบ ATM ซึ่งมีแต่ส่วนตรงกลางเท่านั้นที่เป็น Context ซึ่งระบบนี้มีขอบเขตการทำงานที่เชื่อมต่อกับระบบย่อยอื่นๆ อีก 6 ระบบดังรูป


Behavioral models แบบจำลองพฤติกรรม แบ่งเป็น 2 รูปแบบ
1. Data processing เน้น DFD เน้นแสดงกระบวนการทำงานของระบบ
 ตัวอย่าง Order Processing DFD มีทั้งหมด 5 ขั้นตอน สามารถอธิบายได้ดังรูป

          2. State machine models เน้นสถานการณ์เปลี่ยนแปลงสถานะของอุปกรณ์ทางด้านวิศวกรรมที่
              สร้างขึ้น
             ตัวอย่าง Microwave oven model มีทั้งหมด 8 State สามารถอธิบายได้ดังรูป







Object behavior modeling
      ใช้อธิบายพฤติกรรมของระบบโดยใช้แบบจำลอง Sequence diagram หรือ collaboration diagram
             ตัวอย่าง Sequence Diagram ของระบบห้องสมุด สามารถอธิบายได้ดังรูป

สรุปบทเรียนที่ 12 Software Engineering Test


สรุปบทเรียนที่ 12
Software Engineering Test

เป็นกระบวนการที่เกิดขึ้นหลังจากการพัฒนา Software เสร็จเรียบร้อยแล้ว เพื่อตรวจสอบความผิดพลาดในส่วนต่างๆ ที่เกิดขึ้น แล้วทำการแก้ไข นอกจากนี้เพื่อประเมินคุณภาพและปรับปรุงคุณภาพของ Software
คำศัพท์ในการแก้ไขข้อผิดพลาด
1.  Error การกระทำผิด คือค่าจริงที่ได้จากการทำงานที่ไม่ถูกต้อง
2. Fault ความผิดพลาดหรือข้อบกพร่อง คือกระบวนการทำงานของระบบประมวลผลที่ผิดปกติ
3. Failure ล้มเหลว คือ SW ไม่สามารถทำงานหรือรันโปรแกรมต่อไปได้ รวมถึงไม่สามารถแสดงข้อมูลแจ้งเตือนข้อผิดพลาดที่เกิดขึ้นได้

การทดสอบแบบกล่องดำ Black box testing
เป็นการทดสอบการทำงานของ SW ในเชิงพฤติกรรม 8nv การทดสอบผลของการทำงานของ SW ในแต่ละหน้าที่ ตามข้อกำหนดความต้องการ ทดสอบโดยมองให้เห็นกระบวนการทำงาน สนใจเฉพาะผลลัพธ์ที่ได้เท่านั้น

การทดสอบแบบกล่องขาว White box testing
 เป็นการทดสอบการทำงานของระบบโดยมองลึกลงไปถึง Code คำสั่งต่างๆ ที่อยู่ภายในระบบ
- ทดสอบทุกเส้นทางในกระบวนการ จะต้องสามารถทำงานได้อย่างถูกต้อง
- ทดสอบการทำงานวนซ้ำ Loop
- ทดสอบกระบวนการตัดสินใจในทุกตรรกะ
- ทดสอบโครงสร้างข้อมูลภายในระบบ
Integration testing มี 2 วิธี
1. Top Down Approach ทดสอบการทำงานของระบบแบบบนลงล่าง เป็นการทำสอบการทดงานในฟังก์ชั่นใหญ่ด้านบนก่อนแล้วค่อยๆ ทดสอบฟังก์ชั่นย่อยต่างๆ ที่อยู่ภายใน
2.  Button up Approach ทดสอบการทำงานของระบบแบบล่างขึ้นบน เป็นการทดสอบการทำงานในฟังก์ชั่นการทำงานย่อยภายในฟังก์ชั่นใหญ่ก่อนแล้วค่อยนำฟังก์ชั่นย่อยมาทดสอบรวมกับฟังก์ชั่นใหญ่ด้านบน

ตัวอย่างการทดสอบแบบกล่องขาว White box testing
โดยการทดสอบแบบกล่องขาวมีสูตรการทดสอบดังนี้ V(G) = e-n+2
V= จำนวนเส้นทาง (Path)
e (edges) = จำนวนเส้นเชื่อมของแต่ละโนด
n (node) = จำนวนโนด
                โจทย์
คำอธิบาย: D:\iProject\CS.468 Software Engineering\ตอบคำถามและสรปบทเรียน\img\exam testing white box.jpg
               
                                จากสูตร                 V(G) = e-n+2
                                ตอบ                        V(G) = 10 – 7 + 2
                                                Path 1 = A, B, E, F, G
                                                Path 2 = A, D, E, F, G
                                                Path 3 = A, D, F, G
                                                Path 4 = A, B, C, G
                                                Path 5 = A, B, C, B, C, G