01204341 – Software Engineering

เนื้อหาทั้งหมดต่อจากนี้ถูกเขียนโดยนิสิตภาควิชาวิศวกรรมคอมพิวเตอร์

คณะวิศวกรรมศาสตร์ มหาวิทยาลัยเกษตรศาสตร์ รุ่นที่ 23

โดยเป็นเนื้อหาจากบทเรียนทีเกิดจากการจดบันทึกในห้องเรียนและศึกษาเพิ่มเติมจากนอกห้องเรียน

โดย มีจุดประสงค์เพื่อเป็นแนวทางในการเรียนรู้ของผู้ที่สนใจหรือรุ่นน้องรุ่น ถัดๆไป โดยมีการคงสภาพของเนื้อหาทั้งหมดไว้ทุกประการ รวมถึง คอมเมนท์ ส่วนที่ไม่ใช่เนื้อหาอื่นๆ เป็นต้น

อย่างไรก็ตาม

ในกรณีที่ถูก นำไปใช้หรือนำไปอ้างอิงด้วยวิธีใดวิธีหนึ่งก็ตาม ในกรณีที่เนื้อหาไม่ถูกต้อง ไม่เหมาะสม ผู้เขียนจะไม่ขอรับผิดชอบใดๆทั้งสิ้น ขอให้อ่านด้วยวิจารณญาณของผู้อ่านเอง

ท่านสามารถอ่านเลคเชอร์ฉบับ Document ได้ที่นี่

===============================================

204341 Software Engineering

Software Engineering

Course Information

Lecturer: Asst. Prof. Somnuk Keretho <sk@ku.ac.th>

Office:

Slides:

Book:

Grading

  1. Team Work Performance
  1. Process Work & Presentation (3 rounds) 20%
  2. Product and Presentation (3 rounds) 20%
  1. Individual Performance
  1. Class Participation & Quiz 10%
  2. Midterm 20%
  3. Final 30%

Lecture 1

องค์ประกอบขององค์กรที่ทำงานได้ผลดี

  1. คน (People)
  2. กระบวนการ (Process) เช่น การบริหาร ขีดความสามารถ
  3. เทคโนโลยี (Technology) รวมไปถึงวัตถุและความสามารถ

CMMI (for Development)[1]

CMMI ย่อมาจาก Capability Maturity Model Integration ประกอบด้วย Process Area ทั้งหมด 22 ด้าน โดยแต่ละด้านก็เป็นกระบวนการของตัวเองแยกกัน มีลักษณะเป็นแนวทาง (Guideline) ในการพัฒนาระบบงานให้มีประสิทธิภาพ

CMMI Process Area แบ่งตามระดับมีดังต่อไปนี้

Maturity Level 2 – Managed

  1. CM – Configuration Management
  2. MA – Measurement and Analysis
  3. PMC – Project Monitoring and Control
  4. PP – Project Planning
  5. PPQA – Process and Product Quality Assurance
  6. REQM – Requirements Management
  7. SAM – Supplier Agreement Management

Maturity Level 3 – Defined

  1. DAR – Decision Analysis and Resolution
  2. IPM – Integrated Project Management
  3. OPD – Organizational Process Definition
  4. OPF – Organizational Process Focus
  5. OT – Organizational Training
  6. PI – Product Integration
  7. RD – Requirements Development.
  8. RSKM – Risk Management.
  9. TS – Technical Solution.
  10. VAL – Validation.
  11. VER – Verification.

Maturity Level 4 – Quantitatively Managed

  1. OPP – Organizational Process Performance
  2. QPM – Quantitative Project Management

Maturity Level 5 – Optimizing

  1. CAR – Causal Analysis and Resolution
  2. OPM – Organizational Performance Management

เราสามารถสรุป CMMI ออกมาได้ดังนี้

Continuous Improvement

เกิดจาก 4 ขั้นตอน

  1. กนชจ – กำหนดชัดเจน (Defined)
    มีการกำหนดกระบวนการทำงานทุกส่วนอย่างชัดเจน เช่น การบริหารคน บริหารเวลา
  2. ลลอษ – ลายลักษณ์อักษร (Documented)
    จดบันทึกและทำเอกสารทุกอย่าง ตั้งแต่ความต้องการเป็นต้นมา เพื่อให้เกิดความชัดเจน เพื่อให้ไม่ลืม และเพื่อไม่ให้กำกวม
  3. ชยสค – ใช้อย่างสอดคล้อง (Used Consistently)
  4. ปปตน – ปรับเปลี่ยนต่อเนื่อง (Continuously Improved)
    มีการตอบสนองต่อสิ่งต่างๆ เช่น ปัญหาในระบบงาน และนำมาพัฒนากระบวนการอย่างต่อเนื่อง

Group Project Intro

สิ่งที่ต้องส่ง

  1. ชื่อบริษัท
  2. ชื่อ Project Lead, Asst. Project Lead (PL, APL)
  3. ชื่อ Project Manager, Asst. Project Manager
  4. DM, ADM, ADM, QPM, AQPM, SM, ASM
  5. Email, mobile (PL)

TSPi Process

ในเทอมนี้เราจะทำ 3 Cycle โดยแต่ละ cycle จะเหมือนกัน

  1. Launch
  2. Strategy
  3. Plan
  4. Requirements
  5. Design
  6. Implementation
  7. Test
  8. Postmortem (เป็นช่วงส่งงานและให้คะแนน มีการทบทวนการทำงาน สรุปผล หาข้อปรับปรุง)

โดยแต่ละ Cycle จะใช้เวลา 3-4 สัปดาห์

Lecture 2: Project Launch

Class Announcement

อาจารย์ประกาศ requirement เบื้องต้นแล้ว โปรแกรมมี “หน้า” เป็น HTML5 หลังเป็น PHP+MySQL ใช้ API ที่กำหนดให้

TSPi Process

งานที่ให้ทำจะมี 3 cycle โดย Cycle 1 ใช้เวลา 6 สัปดาห์

หน้าที่หนึ่งของ Support คือการช่วยเตรียมเครื่องมือและระบบ เช่น จัดหา installer และ config compiler ต่างๆ

ช่วงนี้ให้ทำตาม LAU1

1. Launch

  1. Review course objectives
  2. describe TSPi structure and content
  3. จัดทีมและตำแหน่ง
  4. describe customer needs statement
  5. ตั้งเป้าหมายของทีมและแต่ละคน

2. Strategy การกำหนดกลยุทธ

  1. ออกแบบคร่าวๆ เช่น มี front end เป็นอะไร หน้าตาอย่างไร database เขียนอะไรอย่างไร
  2. วางแผนการพัฒนาว่าในแต่ละ cycle จะงอกอะไรขึ้นมา
  3. ประมาณและคะเนขนาดงาน งานแต่ละส่วนกินแรงขนาดไหน
  4. ตั้งแผน configuration management
  5. นำแผนเก่าออกมา
  6. บริหารความเสี่ยง

3. Planning การวางแผนงาน

  1. กำหนดชิ้นงาน (artifact) ว่ามีอะไรบ้าง เขียน SRS & SDS (งาน DM)
  1. requirement กำกวม มีปัญหา ต้องสัมภาษณ์ลูกค้า หรือประชุมตกลงเรื่อง requirement
  1. แบ่งงานเป็นคน มอบหมายลงไปว่าใครทำตอนไหน (PM)
  2. แบ่งงานเป็นสัปดาห์
  3. แผนคุณภาพ

4. Requirements เก็บความต้องการ

  1. วิเคราะห์ สัมภาษณ์ลูกค้า ทำให้ได้ตัว software requirement spec ออกมา

5. Design

  1. ออกแบบระดับสูง
  2. กำหนดแบบ ตรวจแบบ
  3. สร้าง integration test plan

6. Implementation

  1. เขียนโค้ด ทำตัวโปรแกรมขึ้นมา ทดสอบโปรแกรม
  2. เอาโปรแกรมมารวมกันเพื่อทำ integration test

7. Test

  1. Build โปรแกรมขึ้นมาให้เห็นเป็นหน้าๆ ใช้งานได้
  2. ทดสอบระบบ
  3. ทำเอกสาร

8. Postmortem

  1. วิเคราะห์หลังจบงาน
  2. เขียนรายงาน
  3. ประเมินกลุ่ม

TSPi Teams

มีห้าตำแหน่งหลักตามที่ได้เรียนไป แต่อาจมีชื่ออื่นตามแต่บริษัท ทั้งนี้เขาจะต้องกำหนดมา (ตาม กนชจ)

GO LAU1!

  1. ประชุมครั้งแรก
  2. ใช้ Meeting Script
  3. Meeting Goal:
  1. มีข้อมูลทีมเกี่ยวกับโปรเจค ซักซ้อมความเข้าใจ เพราะไม่เคยทำงานกันมาก่อน
  2. ทบทวนหน้าที่ตัวเอง
  3. กำหนดความคาดหวัง

Team Goal (Boilerplate)

  1. Produce a quality product
  1. Measure: Percent of defects found before first compile: 80% (e.g. 20% bug slip)
  2. Measure: Zero bug in system test
  3. Measure: Requirements functioning included at project completion: 100% (คือ เมื่อ requirement เรียบร้อยตามตกลง จะมีการ commit ด้วยสัญญา แล้วทำตามที่ได้มา แล้วต้องเทียบระหว่าง SRS กับโปรแกรมจริง ต้องได้ทุกข้อ)
  1. Run a productive and well-managed project
  1. Measure: Error in estimated product size: < 20%
  2. Measure: Error in estimated development hours < 20%
  3. Measure: Percent of data recorded and entered in project notebook: 100%
  1. Finish on time
  1. Days early/late in completing the development cycle: < 4 days

การทำ Program test จะมีสามรอบ คือ

  1. Unit test = ทดสอบเอง
  2. Integration test = โปรแกรมรวมกันแล้วทดสอบ เช่น PHP mysql call ต่างๆ

PL เสนอ Team Goal, ให้กำลังใจ

งาน Week

  1. กรอกฟอร์ม WEEK
  2. รายงาน
  3. PL เรียกประชุม
  4. Issue Management เช่น ปัญหาต่างๆ ทำยังไง
  5. วางแผนและเดินงานสัปดาห์ถัดไป

Lecture 3: STRAT Phase

งานของสัปดาห์นี้

Conceptual Design

STRAT form

รับ requirement

Project

Web-based database application for LMS

  1. HTML5 (esp. for mobile platform)
  2. PHP
  3. MySQL
  4. API

เนื่องจาก Maxlearn เก่าแล้ว จึงจะพัฒนาใหม่ให้ใช้งานบน mobile platform ได้ มีความทันสมัยมากขึ้น

ข้อกำหนดโดยรวม

ผู้ใช้คือ อาจารย์ เจ้าหน้าที่ นิสิต TA ฯลฯ

เน้น Web Service ในการเชื่อมต่อรับส่งข้อมูลมากขึ้น เชื่อมต่อกับระบบอื่นๆ ด้วย โดยนำข้อมูลมาประมวลผล มีการแสดงผลหลายรูปแบบ

โจทย์มีทั้งหมด 5 ส่วน

  1. ระบบจัดเก็บนำเสนอผลงาน (สื่อการสอน ฯลฯ)
  1. นำส่งผลงานที่ทำไป เช่น final thesis (เล่มแดง) อาจให้ทำเป็น video นำเสนอผลงาน หรือฟอร์แมตอื่น ขึ้นในระบบที่จัดให้
  2. การทำลิงค์เชื่อมโยง เช่น กรณี upload ขึ้น YouTube ทำยังไงก็ได้ให้ upload ผ่าน maxlearn แล้วทะลุไป YouTube เลย หรือจะเก็บลิงค์เอาก็ได้
  3. Upload แล้วต้องมีการแสดงผลด้วย โดยขึ้นกับ browser/platform
  4. อัพแล้วแก้หรือลบได้
  5. กำหนดสิทธิการเข้าถึงไฟล์ได้ เช่น เฉพาะสมาชิกรายวิชา เฉพาะภาควิชา เฉพาะคณะ เฉพาะในมหาวิทยาลัย และ public
  1. ระบบการประเมินผลงาน คือ เมื่ออัพงานมาแล้วจะมีที่ให้ประเมิน
  1. ผู้ดูแลกำหนดว่าจะขึ้นชื่อเจ้าของผลงานหรือไม่
  2. กำหนดวิธีประเมินได้ เช่น
  1. like-only
  2. like/dislike
  3. ประเมินเป็นข้อ ข้อละ 5 ดาว
  1. ผลงานที่ถูกประเมินจะมีคีย์บอกว่าประเมินอะไรอยู่
  2. แสดงผลได้ว่า
  1. ผู้ที่ประเมินแล้ว และยังไม่ได้ประเมิน
  2. ผลงานคะแนนสูงต่ำสุด
  3. ผู้ประเมินคิดเป็นกี่ % ของทั้งหมด
  4. ผู้ดูแลเลือกได้ว่าจะขึ้นข้อไหนบ้าง
  1. ระบบจัดการความเห็น
  1. มี wall ขึ้นมาคล้ายๆ facebook comment
  2. แสดงความคิดเห็นต่อท้ายผลงาน สรุปออกมาได้ว่าใครเขียนแล้ว ใครยังไม่ได้เขียน
  3. ความคิดเห็นสามารถถูกประเมิน like/dislike/ดาว ได้ และจัดเรียงได้
  4. ผู้แสดงความคิดเห็นเป็นกี่เปอร์เซ็นต์
  5. แก้ไข like/dislike ได้
  1. Profile
  1. ข้อมูลบางส่วนเรียกใช้แก้ไขบนมือถือได้สะดวก คือ นำเข้าแก้ไขข้อมูล
  1. รูป ถ่ายจากมือถือได้
  2. ชื่อ สกุล วดปเกิด รหัสนิสิต รหัสประชาชน สาขา ภาควิชา คณะ ฯลฯ
  1. แสดงข้อมูลสรุปว่า
  1. ผู้ใช้ลงหรือสอนวิชาใดบ้าง
  2. จำแนกผู้ใช้ตามสาขา ภาค คณะ ปี
  3. แสดงอาจารย์ที่ปรึกษา และนิสิตในปรึกษา
  1. messaging, wall post ถึงอาจารย์ นิสิต กลุ่ม ชั้นเรียน
  1. การแบ่งกลุ่ม
  1. ใช้ในชั้นใหญ่ๆ เช่น วิชาออนไลน์ Innovative Thinking ออนไลน์ทั้งคณะ
  2. เรียน 1500 คน แบ่งกลุ่มออกเป็น 5 กลุ่ม กลุ่มละ 300 โดยมีอาจารย์ประจำกลุ่ม และในแต่ละกลุ่มก็จะแบ่งเป็น 30 กลุ่ม กลุ่มละ 10 คน
  3. การแบ่งกลุ่มกำหนดได้
  1. กี่กลุ่ม กลุ่มละกี่คน
  2. เลือกเองหรือสุ่ม
  3. ถ้าเลือกเองจะมีชื่อกลุ่มไว้ เลือกเอง
  1. แสดงข้อมูลชั้นเรียนว่าใครอยู่กลุ่มใด จำนวนเท่าใด
  2. ผู้ดูแลย้ายกลุ่มได้
  3. แบ่งกลุ่มซ้อนกลุ่ม
  4. มีหน้าจอที่ใช้ได้สะดวก
  5. เลือกว่าจะให้แสดงหรือไม่ให้แสดงสมาชิกขณะกำลังเลือกกลุ่ม

งานแต่ละกลุ่มมีความสมบูรณ์ในตัว ทำเป็นเอกเทศได้

STRAT1

  1. Conceptual Design
  1. จะสร้างงานนี้อย่างไร
  2. มีองค์ประกอบอะไรบ้าง
  1. ดึงฐานข้อมูลตรงไหน ติดต่ออะไรบ้าง
  1. แต่ละองค์ประกอบทำงานอะไรบ้าง
  2. องค์ประกอบแต่ละชิ้นใหญ่ขนาดไหน

STRAT Form

  1. เขียนความต้องการออกมาเป็นข้อๆ (function)
  2. เขียนความยาวโค้ดที่ต้องการในแต่ละ function (LOC)
  3. เขียนว่าแต่ละ function จะทำใน cycle ใด (มีแค่ 1,2)

ความเสี่ยง

  1. ความเสี่ยงต่างๆ
  1. สิ่งที่ไม่เคยทำ เช่น PHP, Web Service
  2. งานวิชาอื่น
  3. กินหรู
  1. ความเสี่ยงประเมินได้สองมิติ (แต่ละมิติมี High, Medium, Low)
  1. โอกาสที่จะเกิด มักเขียนเป็น prob (Low: น้ำท่วมมหาลัย, High: ท้องเสีย?)
  2. ผลกระทบกับงาน
  1. ให้จับความเสี่ยงมาคูณกัน แล้วหาวิธีแก้ปัญหาล่วงหน้าเลย
  2. กรอกในแบบ ITL (p. 405)

Change Management

(งานฝ่าย support)

  1. เอกสาร
  2. version ของเอกสาร
  3. ปรับปรุงรายงานให้ละเอียดมากขึ้น ควรมีสิ่งที่ทำ และสิ่งที่วางแผนต่อไป

เอกสารควรมีระบบ เช่น <date>-<name>-<proname> ตามนี้เลย

สรุปงาน

  1. อ่าน list of requirements (all)
  2. Conceptual Design (DM&ADM)
  3. Risks (PM&APM)
  4. Configuration management (naming, versioning) (SM&ASM)
  5. Assist with process (PQM & APQM)

สิ่งที่ต้องส่ง

  1. STRAT
  2. WEEK
  3. ITL
  4. รายงานการประชุมและการทำงาน

ส่งก่อนเที่ยงคืน จันทร์หน้า

Lecture 4: PLAN

งานที่จะทำ

  1. เขียนแผนของ cycle 1 วางแผนลงรายละเอียด ว่าจะต้องทำอะไรเมื่อไหร่ ต้องสอนอะไรเพิ่ม ต้องนัดอาจารย์หรือไม่ ฯลฯ
  2. เนื้อหาอ้างตาม chapter 5 และ appendix C

หลักการวางแผน

ทำจากหลังมาหน้า คือเอา output เป็นตัวตั้ง

  1. กำหนด work product / artifact ที่มี เช่น SRS (Software Requirement Specification), HLD (High Level Design), SDP (แผน), โค้ดโปรแกรม, Quality Plan, Test Case & Test Plan ฯลฯ) จะได้เป็น SUMS
  1. SRS, HLD, code => DM
  2. SDP, Quality Plan => PM
  3. Test Cases & Plan => QPM
  1. Unit Test = ทดสอบรายคน แยกส่วนทดสอบ
  2. Integration Test = รวมกันเป็นฝ่ายแล้วทดสอบการ build
  3. System Test = ทดสอบสุดท้าย เน้นเรื่องสมรรถนะด้วยนอกเหนือจากการทำงานได้
  4. User-Acceptance Test (UAT) มักให้ลูกค้าทดสอบ
  1. ระบุงานที่ต้องทำ (TASK) เช่น
  1. SRS ต้องสัมภาษณ์ เก็บ requirement ประชุม กลับมาเขียน เขียนเสร็จให้ลูกค้าดู ฯลฯ
  2. HLD
  3. ฯลฯ
  1. ประมาณเวลาสำหรับแต่ละงานเป็นชั่วโมง (TASK)
  2. แบ่งงาน (TASK)
  3. ทำตารางเป็นรายสัปดาห์ว่าจะทำอะไรวันไหน (SCHEDULE)
  4. เขียน quality plan จะได้เป็น SUMQ

ประเด็นต่างๆ

  1. ทำอย่างไรให้น้ำหนักงานถูกกระจายไปไม่แตกต่างกัน
  2. ติดตามความคืบหน้า เทียบกับแผนของเรา (เอาความคืบหน้าจริงเทียบกับที่คาดการณ์ เช่น task (งาน), effort, cost, value, schedule ว่าตามแผนหรือไม่อย่างไร)
  1. Planned Value (PV) คืออัตราส่วนเป็นเปอร์เซ็นต์ของงานย่อยเทียบกับงานทั้งหมดที่น่าจะเกิด
  2. Earned Value (EV) คือสิ่งที่ได้ทำลงไปจริง
  1. แผนละเอียด (SUMS, TASK, SCHEDULE, SUMQ)
  1. SUMP คือแผนกิจกรรม

PLAN1

  1. SUMS
  2. TASK
  3. SCHEDULE จะหยิบมาจาก TASK โดยลงวันเวลาไปให้เจาะจงมากขึ้น เอาเลขจาก TASK มาใส่ สำหรับ Value ให้คิดแยกมาสำหรับ SCHEDULE ต่างหาก
  4. SUMQ เป็นแผนงานด้านคุณภาพ ก็ลอกๆ ไปก่อนแล้วจะเริ่มเข้าใจ

กิจกรรมกลุ่ม

  1. การทำความเข้าใจ requirements โดยเล่าออกมาเป็นเรื่อง เช่น ใช้ storyboard
  2. เตรียมคำถามเพิ่มเพื่อถามรายละเอียดใน requirements
  3. การบริหารความเสี่ยงจะทำอย่างไร
  4. จัดเอกสารตาม SCRIPT PLAN1 เช่น SUMS TASK SCHEDULE SUMP SUMQ
  5. อ่านหนังสือบทที่ 5 และ Appendix C (Inspections)

Lecture 5: PhoneGap Workshop

Click for more details.

Lecture 6: Requirements

  1. Requirement Elicitation (การรวบรวม requirement)
  2. SRS
  1. มีความชัดเจน ตรวจได้ง่าย (ควรตรวจเป็น ผ่าน/ไม่ผ่าน ชัดๆ)
  1. Requirement Changes (การเปลี่ยนแปลง เกิดจากความเข้าใจ หรือการพัฒนาต่อไปเรื่อยๆ)
  1. เริ่มจาก v0.5
  2. v1.0 จะเป็น baseline requirement เป็นบรรทัดฐานสำหรับการตรวจรับ การทำงาน ฯลฯ
  1. Requirements Traceability
  1. คือการตรวจสอบย้อนไปย้อนมา (ถอยหลังหรือเดินหน้า)
  2. หมายถึง เมื่อเราเริ่มงานเรามี Baseline SRS ทีนี้ต่อมาเรา design จะได้ SDS ออกมา แล้วก็ไปเขียนโปรแกรมออกมาเป็น source แล้ว test ให้เป็นผลงานอีกที

Requirements Elicitation

  1. ต้องประเมินว่าทำได้จริงหรือไม่ (feasible)
  2. ทำความเข้าใจองค์กร เช่น ระบบช่วยเหลือเกษตรกรน้ำท่วม ทำเป็น mobile-only คงไม่เหมาะ
  3. เข้าใจว่าใครใช้งาน ใครมีอำนาจ
  4. บันทึกว่าใครเป็นผู้ให้ความต้องการมาบ้าง
  5. กำหนดว่าสภาพแวดล้อมการทำงานเป็นอย่างไรบ้าง
  6. เข้าใจประเด็นทางธุรกิจ
  7. เข้าใจข้อจำกัด เช่น ความเร็ว ครามทั่วถึง
  8. บันทึกเหตุความต้องการ
  9. ออกแนวคิดหรือ prototype ความต้องการที่เข้าใจยาก
  10. กำหนดเรื่องราวของผู้ใช้ (เราจะพูดว่า ใช้ทำอะไรได้บ้าง ไม่ใช่ทำอย่างไร)
  11. กำหนดขั้นตอนการทำงานของระบบ

สิ่งที่อยู่ใน SRS

  1. ปก
  2. สารบัญ
  3. เกริ่นนำ
  1. วัตถุประสงค์
  2. กล่าวถึงปัญหา (ส่วนใหญ่แถเอา)
  3. ทีมงาน
  1. Functional Requirements คือ ซอฟท์แวร์ทำอะไรบ้าง
  1. อธิบายเป็น use case
  2. Cycle 1 และ Cycle 2
  3. อาจมีโครงสร้างแบบ top-down
  4. เขียน UML เพราะ UML จะแสดง “คน” (Actor – อาจเป็นระบบอื่นที่ไม่ใช่คน)
  1. นิยาม rules หรือ business rules ที่เป็นข้อบังคับ
  1. เช่น การคำนวณภาษีทำด้วยสูตรอะไร
  2. เช่น การออกเอกสารต้องทำตามกฎระเบียบใด
  1. ส่วนติดต่อภายนอก
  1. หน้าจอผู้ใช้ ลงแนวคิดมาก่อนว่ามีอะไรบ้าง การติดต่อกับโปรแกรมอื่น
  2. โครงสร้างหน้าจอ
  1. ข้อจำกัดทางการออกแบบและการ implement
  1. เงื่อนไขมาตรฐานจ่างๆ
  2. ข้อกำหนดในการพัฒนา เช่น ความมั่นคงของระบบ โปรโตคอลที่ใช้
  1. ความต้องการระบบแบบเจาะจง
  1. เอกสาร
  2. ต้องทำงานกับระบบบางประเภทที่กำหนด
  1. เอกสารอ้างอิง

ในการแสดง workflow แนะนำให้ใช้ UML Activity Diagram แบบ swim lane

เงื่อนไขอื่นๆ

  1. Supplementary Specification
  1. การส่งมอบ
  2. เอกสาร
  3. ฯลฯ
  1. Glossary
  1. คำศัพท์ต่างๆ คำเฉพาะ นิยามศัพท์
  1. Vision
  1. Business Rules
  1. อธิบายกฎเกณฑ์ใหญ่ๆ ที่มีอยู่ เช่น กฎหมายภาษี ซึ่งกฎเกณฑ์เหล่านี้เป็นกฎเกณฑ์ทั่วไปที่กว้างกว่างานของเรา

Script

  1. Step 1 – Requirements process overview
  2. Step 2 – Need statement review
  3. Step 3 – Need statement clarification
  4. Step 4 – Requirements tasks
  5. Step 5 – Task allocation
  6. Step 6 – Requirements Documentation
  7. Step 7 – System test plan + Test Cases / Test Scenarios
  8. Step 8 – Requirements and system plan inspection
  1. อ่านใน appendix เก็บไว้หลังมิดเทอม
  1. Step 9 – Requirements Update
  2. Step 10 – User SRS Review
  3. Step 11 – Requirements Baseline

Design Principles

การออกแบบเป็นงานสร้างสรรค์ แต่หลักสำคัญคือพยายามออกแบบในส่วน high-level design (HLD) ก่อน

HLD ประกอบด้วยรายการองค์ประกอบย่อยส่วนต่างๆ เช่น

  1. ขนาดของงาน เช่น บอกว่าโปรแกรมมี 10 หน้า ก็จะมี 10 รายการ ฐานข้อมูลมีกี่ตาราง ฯลฯ
  2. การทำงานในเชิงฟังก์ชัน คือรับค่าอะไร ให้ผลอะไร
  3. หน้าตาของโปรแกรม
  4. สถานะการทำงานต่างๆ (state behavior)

Design for Team

งาน: เขียน HLD v0.2 ออกมาก่อน

Boss Approaching

สอบ Open Book

ตามบทที่ 1-7

Lecture 7: No Class

Lecture 8 (ch.9): Implement and Test

  1. IMP1 = Implementation and Inspection
  1. สร้าง unit test plan ขึ้นมา
  2. การ Test คือ test ว่าให้ bug free
  3. Text ch.8
  1. TEST1
  1. สร้างและทดสอบโปรแกรม
  2. เอาโปรแกรมมารวมกัน และ build ตั้งแต่ต้นจนจบ
  3. Integration Test คือ การทดสอบการเชื่อมโยง เช่น ความเร็ว
  4. สร้าง documentation (เอกสาร) สำหรับผู้ใช้
  5. Text ch.9

วันนี้เรียน Ch.9 ต้อง implement เสร็จและใช้งานได้

QPM ตรวจสอบ bug, defect ต่างๆ แล้วให้แก้ไขให้ถูกต้อง

เนื้อหา

  1. Testing Principles
  2. Test Strategies
  3. Testing Planning
  4. Test measurement and tracking
  5. Defect-prone modules

Testing Principles

หลักการของ (integrating/system) testing ใน TSPi คือการประเมินตัว product ไม่ใช่การแก้ไขปัญหา แต่บอกว่ามีปัญหาตรงไหนบ้าง ผู้รับผิดชอบจะแก้ไขเอง ทั้งนี้ สำคัญตรงที่ ปัญหาควรหมดไป ไม่มีปัญหาในส่วนของตัวเองแล้วก่อน คือทำ unit test ให้ผ่านก่อนจึงค่อยไปเข้า test phase ที่เป็นเช่นนี้เพราะถ้ามีบั๊กติดไปใน integration test จะแก้ไขได้ยากมาก

การเขียนโปรแกรมบางอย่างอาจสร้าง testbed ก่อนแล้วค่อยสร้างโปรแกรมจริงๆ ก็มี

defect บางตัวมีอันตรายถึงตาย หรือทำให้ธุรกิจล่มสลาย ดังนั้น การหา defect และแก้ไขให้ทันท่วงทีจึงสำคัญ

หลักการทดสอบของ TSPi คือการเอาโปรแกรมที่ดีแล้วมาทดสอบ ไม่ใช่การเอาโปรแกรมอะไรก็ไม่รู้มาทำดังนั้น เมื่อเราเข้าสู่ testing แล้วเราก็มาทดสอบเฉพาะปัญหาระดับสูงเท่านั้น

ในการ test เราจะใช้กิจกรรมดังต่อไปนี้

  1. สร้างโปรแกรมจากส่วนของโปรแกรมที่ทดสอบมาดีแล้ว
  2. Integration-Test เพื่อ Verify ในระดับเบื้องต้นว่าสามารถทำงานได้ถูกต้องหรือไม่ ยังไม่สนใจ specs เน้นประสิทธิภาพเป็นหลัก
  3. System-Test เพื่อ Validate ว่าตรงตามความต้องการหรือไม่ มีความครบถ้วนเพียงพอหรือยัง
  4. User-Acceptance Test (UAT) เป็นการทดสอบในสภาพของผู้ใช้

Testing Strategy

  1. QPM ตรวจว่ามีโปรแกรมที่น่าจะมีปัญหาหรือไม่ ถ้ามีก็ส่งกลับให้ไปแก้ให้เรียบร้อย
  2. ถ้ายังมีปัญหาต่อเนื่องให้โยนทิ้งได้ อาจต้องเขียนใหม่ทั้งหมด
  3. เมื่อใช้ได้แล้วก็เอามา build, integration test, system test และ UAT

The 2 V’s

Verification = ทดสอบ

สิ่งที่เราทำเป็นไปตาม requirement (“Build the Product Right”) เทียบกับ specs ที่ได้มาเท่านั้น ทำได้ถูกต้องแล้วหรือยัง

Validation = ทวนสอบ

เป็นการทดสอบให้เห็นว่าชิ้นงานของเราทำตามที่ต้องการ คือเป็นเป้าประสงค์ในสภาวะแวดล้อมที่กำหนด อาจพูดว่า “Build the Right Product” ก็ได้

Build and Integration Strategy

Big-Bang Strategy

เป็นการทดสอบทั้งหมดครั้งเดียว เสียเวลาน้อย แต่เสียหายมากถ้ามี defect เกิดขึ้น

One-at-aTime Strategy

เป็นการทดสอบโดยเติมเข้าไปทีละ module ทำให้ต้องทดสอบมาก แต่สามารถหาปัญหาได้ง่ายกว่า และแก้ปัญหาได้ง่าย

Cluster Strategy

เป็นการเพิ่ม module เข้าไปทีละกลุ่ม โดยเพิ่มกลุ่มที่ใกล้ๆ กันลงไปทีละกลุ่ม

Flat-system Strategy

เป็นการใส่ลงไปทีละ level เช่น ใส่จากล่างขึ้นบน หรือจากบนลงล่าง (เช่น UI -> Database เป็นต้น)

System Test Strategy

ทดสอบการทำงานว่าตรงตาม SRS หรือไม่ โดยมี 4 คำถาม

  1. ทำงานตามที่ควรจะเป็นหรือไม่
  2. เป็นไปตามเป้าหมายคุณภาพหรือไม่ เช่น bug-free
  3. ทำงานได้ดีในสภาวะปกติหรือไม่
  4. ทำงานได้ดีในสภาวะผิดปกติหรือไม่

เราอาจสนใจเงื่อนไขต่างๆ เช่น

  1. ติดตั้งง่าย
  2. เปิดใช้งานได้
  3. ทำตาม requirement
  4. กู้จากสภาพ failure ได้

ฯลฯ

ในการทดสอบจริง อาจทดสอบจาก

  1. ตามวัตถุประสงค์
  2. ตามการทำงาน

Homework

23 กุมภาพันธ์ ส่ง SDS ตัวใหม่

INS for SDS

Plan (implement, unit test, integration test, system test, presentation preparation plan)

Presenation

Presentation

Process

Work Product

Demo Product

Submit

SRS 1.0

SDS 1.0

Code 1.0

INS

LOGT

LOGD

SUMP

SUMQ

Project Workbook

Lecture 9

Postmortem

คือช่วงเวลาที่เอาไว้ทบทวนการทำงานของเราตลอด cycle ที่ผ่านมาว่ามีอะไรที่ผิดพลาดต้องแก้ไข หรืออะไรที่ดีและต้องพัฒนาให้มากขึ้น

ควรทำ Postmortem เพื่อเป็นการประเมินตนเองไม่ว่าจะเสร็จงานใดๆ รอบใดๆ ก็ตาม ทำให้เกิดการพัฒนาและปรับปรุงตนเอง คือ การปรับปรุงตนเองอย่างต่อเนื่องตลอดชีวิต (Continuous Improvement)

งานที่ต้องทำ

วันที่ 8 มีนาคมก่อนเที่ยงคืน

  1. ส่งงาน Postmortem Phase (ดูงานตาม Chapter 10)
  1. PIP (Process Improvement Proposal)
  2. PEER (ประเมินการทำงานในกลุ่ม มีประเมินตนเองด้วย)
  3. Cycle Report (รายงาน)

Cycle 2

 

Week

Date

Step

11

6 Mar

LAU2 (Reform Teams, Read Ch. 11-15)

STRAT2 (Produce strat. & plan. for cycle 2)

PLAN2 (Risk assessment)

** may start coding if applicable

12

13 Mar

REQ2 (Update requirements)

DES2 (Update SDS & Integration Plan)

13

20 Mar

IMP2

TEST2

PM2

14

27 Mar

Final (Present Cycle 2)

15

8 Apr

สอบข้อเขียน

การสลับตำแหน่ง อาจสลับตำแหน่งใน engineering บ้าง แต่ไม่น่ามีการสลับตำแหน่งบริหาร

PIP

ข้อแนะนำจากอาจารย์

  1. ควรมีกระดาษโน้ตติดตัวไว้ คิดอะไรออกจดเลย เดี๋ยวลืม
  2. สำหรับทีมที่เป็น extreme coding อาจมีการทำ postmortem วันละรอบ

เขียนเพื่อเสนอการพัฒนากระบวนการของเรา โดยทุกคนสามารถเสนอได้ แล้ว QPM จะนำมาสรุปอีกที และอาจนำข้อเสนอบางอย่างขึ้นที่ประชุมได้ด้วย ดูหน้า 415-416

PM1

  1. Postmortem Process Overview
  2. Review process data (QPM Leads) เช่น ดูข้อมูลจาก SUMP SUMQ ว่างานไหนพัฒนาได้อีกบ้าง
  3. Evaluate role performance (PL Leads)

Cycle Report

  1. Table of Content
  2. Summary
  3. Role Report คือการให้คะแนนตามบทบาท โดยเทียบกับความคาดหวังของตำแหน่งนั้น
  1. Leadership -> PL
  2. Development -> DM
  3. Planning -> PM
  4. Process
  5. Quality -> QM
  6. Support -> SM

PEER

แต่ละคนส่งฟอร์ม PEER ตามหน้า 194

Class Announcement

กำหนดการนำเสนอ

นำเสนอวันที่ 27 มีนาคม 2555 แต่ละกลุ่มมีเวลา 45 นาที ให้นำเสนอทั้งส่วนของผลงาน (ประมาณ 12 นาทีแรก) และส่วนของกระบวนการ (12 นาทีต่อมา) ตามลำดับกลุ่มต่อไปนี้

  1. 1230-1315: BatManJarb
  2. 1315-1400: EggPlant
  3. 1400-1445: iOne
  4. 1445-1530: Khaopui
  5. 1530-1645: SeeMyEyes

การถามคำถามอาจเป็นทีมหรือเป็นรายบุคคล จึงควรมีการเตรียมตัวทั้งกลุ่ม และมีผลกับคะแนนสอบค่อนข้างมาก

Teacher’s Notes

  1. ตอนที่ส่งงานแล้ว ควรจะมี SRS ประกอบมาด้วย
  2. ITP ส่งคู่กับ SDS

การสอบ

  1. 8 เมษายน 2555 1300-1600 ห้อง 3403
  2. นำหนังสือเข้าได้ (เท่านั้น)
  3. สอบตามหนังสือ + Group Project + Introduction to CMMI

Lecture 9: CMMI

*** บทนี้เนื้อหาส่วนใหญ่จะอยู่ในบทแรกแล้วนะ ***

CMMI?

Capability Maturity Model Integration (CMMI) เป็นกรอบแนวทาง (Framework/Model) ในการปรับปรุงองค์กรให้มีขีดความสามารถในการพัฒนาซอฟท์แวร์ที่มีคุณภาพ

อีกแนวทางหนึ่งคือ CMMI เป็น Process Model = แบบจำลองด้านกระบวนการทำงาน ที่กำหนดว่าจะปฏิบัติอย่างไรให้บรรลุเป้าหมาย โดย CMMI ประกอบไปด้วย process area ทั้งหมด 22 ด้าน

ที่มาและปัญหา

โครงการซอฟท์แวร์ทั่วโลก มีเพียง 26% ที่ส่งทันเวลา ทำได้ตามสัญญา และอยู่ในงบประมาณที่กำหนด

การจะทำซอฟท์แวร์ให้สำเร็จ ต้องมีสามด้านคือกระบวนการ เทคโนโลยี และบุคลากร

d

Process Areas

Process Area ของ CMMI ถูกแบ่งเป็น 22 ด้าน คือ (กลับไปดูหน้าแรก)

ใน Level 2 มี 7 ตัวที่ควรรู้ (ดูหน้าแรกเช่นกัน)

Final Maturity

จบโครงการในชั้นเรียน ตอนนี้เราอยู่ประมาณระดับ 2.5 ถึง 3 การจะขึ้นถึงระดับ 4 ได้จำเป็นจะต้องทำงานมาแล้วพอสมควรก่อน เพราะ CMMI พัฒนาจากข้อมูล ประสบการณ์ และสถิติในอดีต มาพัฒนากระบวนการของเรา

การจะขึ้นถึงระดับที่ 5 ได้จะต้องมีการพัฒนากระบวนการทำงานอย่างต่อเนื่อง มีการปรับปรุงตนเองอย่างเป็นระบบ

Summary

  1. CMMI เป็น Process Model มี 22 ด้าน
  2. Process Model = ไม่ได้ลงในรายละเอียด เป็นเพียงแบบจำลอง เรามีหน้าที่กำหนดแบบการทำงานเอง ว่าจะทำในรายละเอียดอย่างไร
  3. TSP ที่เราเรียนมา เป็นตัวอย่างหนึ่งของ process คือเป็น process implementation (นั่นคือ CMMI เป็น “What” — “ต้องวางแผน”, TSP เป็น “How” — “เขียน STRAT, TASK, ฯลฯ”)
  4. ในการทำงาน ให้แยกหลักการกับวิธีการออกจากกัน วิธีการอาจเปลี่ยนแปลงได้เร็วและง่าย ในขณะที่หลักการมีรูปแบบระยะยาวกว่า CMMI ก็เป็น “หลักการ” อย่างหนึ่งที่เป็นสากล แน่นอนว่าองค์กรแต่ละแห่งจะเลือกวิธีการใดมาใช้ก็ได้ ในที่นี้เราใช้ TSP

Comments are closed.