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

ตอบคำถามบทเรียนที่ 5

แบบฝึกหัดบทเรียนที่ 5

      ให้นักศึกาเขียนเอกสารความต้องการซอฟต์แวร์ โดยนำเอาโครงงานวิชาการของนักศึกษามาจัดทำ

ตอบ คลิก >> Developing Application For Lock-UnlockAutomatic Door System

ตอบคำถามบทเรียนที่ 7


แบบฝึกหัดบทที่ 7
        1. จงอธิบาย Context Models ของระบบเอทีเอ็ม


               จากภาพ Context Diagram ของระบบเอทีเอ็ม สามารถอธิบายได้ถึงขอบเขตการเชื่อมโยงของระบบเอทีเอ็มได้ว่ามีการเชื่อมโยงกับระบบใดบ้าง โดยมีระบบที่เชื่อมโยงกับระบบเอทีเอ็มสามารถอธิบายได้ดังภาพ เช่น ระบบเอทีเอ็มมีการเชื่อมโยงกับระบบฐานข้อมูลลูกค้า เพื่อใช้ในการเรียกข้อมูลเลขที่บัญชีลูกค้าในการทำธุรกรรมทางการเงินทางตู้เอทีเอ็ม เป็นต้น


        2. จงอธิบาย Process Models ของระบบการเรียนออนไลน์



        3. จงอธิบาย Behavioral Models ของระบบการวางใบสั่งซื้อ (Order)



จากภาพ Behavioral Model แสดถึงกระบวนการวางใบสั่งซื้อ มี 5 Process และผลลัพธ์ที่ได้ มี 2 Entity โดยสามารถอธิบายได้ดังนี้
1. กรอกข้อมูลใบสั่งซื้อให้ถูกต้องสมบรูณ์
2. ตรวจสอบ Order ว่าสมบรูณ์ถูกต้องไหม
3. จัดเก็บ Order ในขั้นตอนนี้จะได้ไฟล์ Order และทำการจัดเก็บ
4. จากนั้นตอนที่ 3 ใบขั้นตอนต่อไปสามารถดำเนินการได้ 2 กระบวนการ คือ ขั้นตอนที่ 4 และ 5
5. ส่งข้อมูลใบสั่งซื้อไปยัง Supplier
6. ในข้อมูลใบสั่งซื้อมาทำการปรับยอดใหม่ ในขั้นตอนนี้จะได้ไฟล์งบประมาณ
   
       4 . จงอธิบาย Object Models ของระบบห้องสมุด
          สามารถอธิบายพฤติกรรมของระบบ เช่น การติดต่อสื่อสารกันระหว่าง Object ของระบบห้องสมุดสามารถอธิบายได้ดังภาพ Object Model ต่อไปนี้




ตอบคำถามบทเรียนที่ 6


แบบฝึกหัดบทที่ 6
ระบบการจองตั๋วหนังเพื่อเข้าชมการแสดง ให้นักศึกษา ศึกษาเอกสารกำหนดความต้องการที่กำหนดให้ และให้วิเคราะห์ว่าข้อความใดที่บ่งบอกถึง ความต้องการที่เป็นหน้าที่หลักของระบบ (Functional Requirement) และข้อความใดบ่งบอกถึง ความต้องการที่ไม่ใช่หน้าที่หลักของระบบ (Non-Functional Requirement) บริษัท KBU Ticket Master ต้องการสร้างระบบให้ลูกค้าสามารถจองตั๋วชมการแสดง ผ่านทางระบบ Internet โดยกำหนดความต้องการของระบบดังนี้
       -  การแสดงหนึ่งๆ อาจจะมีรอบการแสดง ได้มากกว่าหนึ่งรอบได้
       -  การแสดงแต่ละรอบจะจัดแสดงอยู่ในโรงละคร ซึ่งแต่ละโรงละครจะมีจำนวนที่นั่งแตกต่างกัน
       -  ในการจองที่นั่งแต่ละรอบจะมีการกำหนดว่าลูกค้าหนึ่งคนจะสามารถจองตั๋วได้มากที่สุดจำนวนกี่ที่นั่ง
       -   ลูกค้าสามารถคืนตั๋วได้(โดยได้รับเงินคืน) แต่ต้องคืนภายในเวลาที่กำหนด ซึ่งเวลาที่กำหนดนั้นจะไม่เท่ากัน ขึ้นอยู่
                 กับการแสดงในแต่ละรอบ
       -   การบริหารจัดการตารางการแสดงแต่ละรอบ และแต่ละโรงละคร จะต้องไม่ยุ่งยากใช้พนักงานให้น้อยที่สุด
       -   ระบบใช้งานได้ง่าย ลูกค้าสามารถเรียนรู้ขั้นตอนวิธีการจองตั๋วชมการแสดง ได้อย่างรวดเร็ว
       -   ระบบจะต้องตอบสนองการใช้งานของลูกค้าได้อย่างรวดเร็วและถูกต้อง

Functional Requirement
Non-Functional Requirement
     - การแสดงหนึ่งๆ อาจจะมีรอบการแสดง ได้มากกว่า หนึ่งรอบได้
     - การบริหารจัดการตารางการแสดงแต่ละรอบ และแต่ละโรงละคร จะต้องไม่ยุ่งยากใช้พนักงานให้น้อยที่สุด
     - การแสดงแต่ละรอบจะจัดแสดงอยู่ในโรงละคร ซึ่งแต่ละโรงละครจะมีจำนวนที่นั่งแตกต่างกัน
     - ระบบใช้งานได้ง่าย ลูกค้าสามารถเรียนรู้ขั้นตอนวิธีการจองตั๋วชมการแสดง ได้อย่างรวดเร็ว
     - การจองที่นั่งแต่ละรอบจะมีการกำหนดว่าลูกค้าหนึ่งคนจะสามารถจองตั๋วได้มากที่สุดจำนวนกี่ที่นั่ง
     - ลูกค้าสามารถคืนตั๋วได้(โดยได้รับเงินคืน) แต่ต้องคืนภายในเวลาที่กำหนด ซึ่งเวลาที่กำหนดนั้นจะไม่เท่ากัน ขึ้นอยู่กับการแสดงในแต่ละรอบ
     - ระบบจะต้องตอบสนองการใช้งานของลูกค้าได้อย่างรวดเร็วและถูกต้อง



สรุปบทเรียนที่ 5 Software Requirement


สรุปบทเรียนที่ 5
Software Requirement

Requirement Engineering วิศวกรรมความต้องการ
                หมายถึง กระบวนการที่ทำให้วิศวกรรมซอฟต์แวร์เขข้าใจถึงความต้องการที่แท้จริงของลูกค้าได้อย่างแท้จริง ซึ่งมี 4 วิธี
1. จะต้องไปค้นหาความต้องการของผู้ใช้
2. นำความต้องการที่ได้ไปทำการวิเคราะห์
3. กำหนดความต้องการ
4. ตรวจสอบความต้องการ

ตัวอย่าง Functional Requirements (มักจะขึ้นต้นด้วย จะ”) เช่น
1. ผู้ใช้จะสามารถค้นหาบทความทั้งหมดหรือสามารถเลือกค้นหาได้
2. ระบบจะให้ผู้อ่านสามารถอ่านบทความที่เก็บเอาไว้ในฐานข้อมูลได้

Non-functional requirement แบ่งออกได้เป็น 3 ด้าน
1. Product requirement ความต้องการทางด้านผลิตภัณฑ์ เช่น ประสิทธิภาพของผลิตภัณฑ์ ความน่าเชื่อถือ
2. Organizational requirement ความต้องการทางด้านองค์กร เช่น นโยบายขององค์กร ข้อกำหนดขององค์กร ระเบียบปฏิบัติของลูกค้า
3. External requirement ความต้องการภายนอก เช่น กฎหมาย นโยบายขององค์กร ของสังคม เกี่ยวกับสินค้า หลักทางด้านจริยธรรม

Sequence Diagram
เป็นแผนภาพแสดงปฏิสัมพันธ์ระหว่าง Object และ Class โดยการส่งข้อความ (Message) ระหว่างกัน
ตัวอย่าง Sequence Diagram ของระบบห้องสมุด สามารถอธิบายได้ดังภาพตัวอย่าง





สรุปบทเรียนที่ 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.  สภาพแวดล้อม และ เทคโนโลยี เมื่อเกิดการเปลี่ยนแปลง ก็จะต้องมีการเปลี่ยนแปลงความต้องการให้มีความสอดคล้อง และ เหมาะสม