การเขียนโครงการ และ การบริหารโครงการ

1. การเขียนโครงการและการบริหารโครงการการเขียนโครงการและการบริหารโครงการ

2. ความยากในการพัฒนาซอฟต์แวร์ความยากในการพัฒนาซอฟต์แวร์ • ผู้ใช้ไม่ทราบว่าตนเองต้องการอะไรกันแน่ • ผู้พัฒนาต้องขุดคุ้ยความต้องการของผู้ใช้ออกมา และเรียบเรียงให้ชัดเจน • ความเปลี่ยนแปลงในด้านเทคโนโลยี เช่น ฮาร์ดแวร์ ภาษาที่ใช้ เครื่องมือ ฯลฯ • งบประมาณ ความเร่งด่วน • ความต้องการของผู้ใช้ที่มักเปลี่ยนไปเปลี่ยนมา • ที่สำคัญที่สุดคือ คน ทั้งที่เป็น ผู้ใช้ และผู้พัฒนา

3. การเขียนโครงการ • ในการพัฒนาซอฟต์แวร์ถือว่า “จุดเริ่มต้นเป็นส่วนที่สำคัญที่สุด” • จุดเริ่มต้นที่สำคัญก็คือ การทำความเข้าใจขอบเขต และรายละเอียดของโครงการ แล้วประเมินค่าใช้จ่ายออกมา • การเขียนโครงการก่อนเริ่มพัฒนาจริง เป็นการบังคับให้เรามีการวิเคราะห์และตรวจสอบเป้าหมายและรายละเอียดของสิ่งที่จะต้องทำอย่างจริงจัง • เป็นโอกาสให้เราจะได้ทบทวนปัญหาหรือความเสี่ยงที่อาจจะเกิดขึ้นและเตรียมพร้อมรับมือล่วงหน้า

4. ความสำคัญของการเขียนโครงการความสำคัญของการเขียนโครงการ • กำหนดเป้าหมาย ขอบเขตการทำงานของซอฟต์แวร์ เนื้องาน และทีมงาน ฯลฯ • ทบทวนความเสี่ยงและปัญหาที่อาจเกิดขึ้น • เป็นนโยบายในการทำงานของสมาชิกโครงการ • ทำให้สมาชิกแต่ละคนทำงานได้ราบรื่น • เป็นอาวุธช่วยให้ผู้จัดการโครงการแสดงภาวะผู้นำ

5. การบริหารโครงการ • การบริหารโครงการคือ การติดตามว่าโครงการคืบหน้าแค่ไหน ติดปัญหาอะไรอยู่ และจัดการทรัพยากรให้โครงการสำเร็จตามเป้าหมาย ภายใต้ระยะเวลาและงบประมาณที่มี • ในการบริหารโครงการต้องเข้าใจสถานการณ์ของโครงการเป็นอย่างดี ในแง่ค่าใช้จ่ายที่เกิดขึ้น ระดับความคืบหน้า คุณภาพของงาน ฯลฯ • ต้องทำรายงานให้ผู้ที่เกี่ยวข้อง “มองเห็นแล้วเข้าใจทันที” ว่าตอนนี้โครงการมีความคืบหน้าอย่างไร หากโครงการไม่คืบหน้าตามแผน ก็แสดงว่ามีปัญหาเกิดขึ้น ผู้จัดการโครงการต้องหาสาเหตุแลกำหนดมาตราการแก้ไข

6. ความสำคัญของการบริหารโครงการความสำคัญของการบริหารโครงการ • ช่วยให้เข้าใจความคืบหน้าและการใช้งบประมาณ • ทำให้ผู้เกี่ยวข้องที่ได้รับผลกระทบเข้าใจได้ทันทีว่าโครงการมีความคืบหน้าอย่างไร • เห็นปัญหาจากการดูว่าความคืบหน้าเป็นไปตามแผนหรือไม่ ช่วยให้วิเคราะห์และกำหนดมาตรการแก้ไขปัญหาได้ถูกต้อง

7. ประเด็นสำหรับการเขียนโครงการและบริหารโครงการประเด็นสำหรับการเขียนโครงการและบริหารโครงการ

8. การบริหารโครงการ Project Management มี 9 เรื่องที่ควรพิจารณา • การบริหารภาพรวม (Total Management) • การบริหารขอบเขต (Scope Management) • การบริหารเวลา (Time Management) • การบริหารค่าใช้จ่าย (Cost Management) • การบริหารคุณภาพ (Quality Management) • การบริหารองค์กร (Organization Management) • การบริหารการสื่อสาร (Communication Management) • การบริหารอุปทาน(Supply Management) • การบริหารความเสี่ยง (Risk Management)

9. การเขียนโครงการและบริหารโครงการการเขียนโครงการและบริหารโครงการ นิยามขอบเขต เขียนโครงการและบริหารโครงการ วางแผนและบริหารขอบเขต บริหารการเปลี่ยนแปลง บริหารผลลัพธ์ นิยามงานย่อย วางแผนและบริหารกำหนดการ บริหารกำหนดการ การนิยามขอบเขต วางแผนคุณภาพ วางแผนและบริหารคุณภาพ ประกันคุณภาพ บริหารคุณภาพ ระบุความเสี่ยง วางแผนและบริหารความเสี่ยง กำหนดมาตรการรองรับความเสี่ยง บริหารความเสี่ยง

10. การวางแผนบริหารขอบเขตการวางแผนบริหารขอบเขต • พิจารณาดูแผนงานของโครงการว่ามีขอบเขตแค่ไหน (ขอบเขตจะถูกกำหนดขึ้นตามความต้องการและความคาดหวังของลูกค้า) เรียกขั้นตอนนี้ว่า การวางแผนขอบเขต(Scope Planning) • การบริหารความเปลี่ยนแปลง เป็นการรักษาคุณภาพร่วมกับลูกค้า • นิยามและบริหารสิ่งเกิดขึ้นจากโครงการ เช่น ตัวโปรแกรม เอกสาร การออกแบบ คู่มือการใช้งาน ฯลฯ

11. การวางแผนบริหารขอบเขตการวางแผนบริหารขอบเขต การวางแผนและบริหารขอบเขต นิยามขอบเขต บริหารการเปลี่ยนแปลง บริหารผลลัพธ์ ผลลัพธ์ระหว่างการพัฒนา ผลลัพธ์สุดท้าย

12. วางแผนและบริหารกำหนดการวางแผนและบริหารกำหนดการ • กำหนดว่าเมื่อไหร่จะส่งมอบงานให้ลูกค้า • ต้องควบคุมงานพัฒนาให้เดินหน้าทันเวลานัดส่งมอบงาน • ต้องมองเห็นเนื้องานที่ต้องทำทั้งหมดตั้งแต่การวางแผนและบริหารขอบเขต • แบ่งงานต่าง ๆ ออกเป็นงานย่อย แล้วดูว่าจะต้องทำงานไหนก่อน-หลัง

13. WBS (Work Breakdown Structure)

14. A2 C1 C2 A3 A1 B C3 A4 A5 A6 วางแผนและบริหารกำหนดการ(ต่อ) เทคนิคการจัด Schedule • Network diagram เช่น PERT diagram • Gant Chart หรือ Bar Chart

15. การวางแผนและบริหารคุณภาพการวางแผนและบริหารคุณภาพ • คุณภาพมีประเด็น คือ งานที่ออกมาตรงกับความต้องการของลูกค้าหรือไม่(เป็นเหตุผลให้ลูกค้าพึงพอใจ) และซอฟต์แวร์ไม่มีปัญหาทางด้านเทคนิค คือ มีความผิดพลาดน้อย

16. บริหารความเสี่ยง • ความเสี่ยงในกรณีการพัฒนาซอฟต์แวร์คือ สิ่งที่อาจมีผลทำให้โครงการพัฒนาซอฟต์แวร์ไม่ประสบความสำเร็จ ความเสี่ยงที่พบโดยทั่วไปได้แก่ • โครงการที่มีขนาดใหญ่และมีความซับซ้อน • ความคลาดเคลื่อนในการเสนอราคา • ความเปลี่ยนแปลงด้านความต้องการ • ความผิดพลาดในการออกแบบระบบ (ออกแบบไม่ครบ หรือเข้าใจผิด) • การขาดทักษะด้านเทคนิค หรือขาดความรู้ด้านวิธีการทำงานของลูกค้า • การใช้ฮาร์ดแวร์หรือซอฟต์แวร์ใหม่

17. การวางแผนและบริหารคน • การบริหารคนไม่ให้เกิดปัญหา เป็นสิ่งสำคัญที่สุดในการบริหารโครงการ • เริ่มจากการเตรียมทีมงานรองรับตามขนาดของงานที่ประเมินไว้ • การวางแผนการสื่อสาร เช่นต้องมีการติดต่อสื่อสาร ประสานงานกับใครบ้าง ต้องมีการจัดเอกสารอะไรและส่งให้ใครบ้าง

18. บริษัทที่ต้องการใช้ซอฟต์แวร์บริษัทที่ต้องการใช้ซอฟต์แวร์ ทีมงานพัฒนา กลุ่มผู้ใช้ซอฟต์แวร์ (End User) Project Manager (1 คน) หน่วยงานด้านสารสนเทศ Project Staff (0-2 คน) Project Leader (1 คน) Programmer (หลายคน) Project Leader (1 คน) Programmer (หลายคน) Project Leader (1 คน) Programmer (หลายคน)

19. การวางแผนและบริหารอุปทานการวางแผนและบริหารอุปทาน • ในการพัฒนาซอฟต์แวร์บางครั้งต้องมีการใช้ sub-contract (บริษัทอื่นมารับงานบางช่วง) มาช่วยงานด้วย • ในการบริหาร sub-contract ต้องระมัดระวังเรื่องเวลาในการส่งมอบงาน คุณภาพและค่าใช้จ่าย • การบริหารอุปทานยังรวมถึง การบริหาร supplier ที่ขายสินค้าต่าง ๆ ให้เรา เช่น software package , tools ในการพัฒนา หรือ Hardware ต่าง ๆ

20. การวางแผนและบริหารค่าใช้จ่ายการวางแผนและบริหารค่าใช้จ่าย • ค่าใช้จ่ายในการพัฒนา ประกอบด้วย • ค่าใช้จ่ายทางตรง เช่น ค่าจ้างพนักงาน ค่าจ้าง sub contract • ค่าใช้จ่ายทางอ้อม เช่น ค่าใช้จ่ายด้านอุปกรณ์ และด้านธุรการ เช่น ค่า โทรศัพท์ ค่ารถ ฯลฯ • ประเมินค่าใช้จ่ายจากงานที่ต้องทำ

21. การวางแผนและบริหารสิ่งแวดล้อมในการพัฒนาการวางแผนและบริหารสิ่งแวดล้อมในการพัฒนา • ปกติผู้พัฒนาซอฟต์แวร์จะเป็นผู้รับผิดชอบเตรียมสิ่งแวดล้อมในการทำงานเอง เช่น เครื่องคอมพิวเตอร์ ซอฟต์แวร์ tools ต่าง ๆ • แต่บางกรณีลูกค้าก็จะเป็นผู้จัดหามาให้

22. เอกสารโครงการ เนื้อหาของเอกสารของโครงการ ประกอบด้วย • เป้าหมายและวัตถุประสงค์ของโครงการ ขอบเขต สมมติฐาน • แผนบริหารโครงการ(แผนคุณภาพ แผนค่าใช้จ่าย แผนจัดการปัญหา แผนบริหารความเสี่ยง แผนการสื่อสาร แผนการทบทวน) • เอาต์พุตของโครงการ(สิ่งที่ต้องส่งมอบ วันที่ส่ง สื่อที่ใช้) • แผนบริหารทีมงาน(โครงสร้างทีมงาน จำนวนคนที่ต้องการในแต่ละเดือน แผนการฝึกอบรม) • แผนเกี่ยวกับเนื้องานและกำหนดการ(WBS การระดมสมอง กำหนดการทำงาน) • แผนบริหารอุปทาน(เอาต์พุตที่ต้องการ เวลาตรวจรับงาน วันชำระเงิน)

23. ประเด็นในการเขียนโครงการประเด็นในการเขียนโครงการ • เริ่มจากศึกษาความต้องการและขอบเขต แล้วประเมินขนาดของโครงการ • เขียนโครงการตามขั้นตอนมาตรฐาน • ค่อย ๆ ทบทวน แล้วเพิ่มรายละเอียด

24. ศึกษาความต้องการและขอบเขตศึกษาความต้องการและขอบเขต การนิยามขอบเขตของโครงการ มีสาระดังนี้ • แผนโครงการต้องระบุให้ชัดเจนว่าจะต้องทำอะไรบ้าง • ในการพัฒนาซอฟต์แวร์ จุดเริ่มต้นคือ ความต้องการ ความคาดหวังของลูกค้า ซึ่งจับต้องยาก • ศึกษาให้รู้ว่าเป้าหมายหรือวัตถุประสงค์ของการพัฒนาซอฟต์แวร์ที่ได้รับมอบหมายคืออะไร • ขอบเขตของระบบงานที่จะนำซอฟต์แวร์ไปใช้มีแค่ไหน • หลังนำซอฟต์แวร์ไปใช้แล้ว วิธีการทำงานแบบใหม่เป็นอย่างไร • ข้อมูลจากระบบใหม่จะถูกนำไปใช้ประโยชน์อย่างไร

25. ศึกษาความต้องการและขอบเขต(ต่อ)ศึกษาความต้องการและขอบเขต(ต่อ) แผนพัฒนา ทีมงาน ค่าใช้จ่าย กำหนดการ ระยะเวลา ศึกษาความต้องการและขอบเขต ประเมินขนาดของโครงการ • หลังจากนิยามขอบเขตแล้ว ก็ต้องประเมินขนาดของโครงการ • พิจารณาเลือกวิธีการพัฒนา • สรุปขั้นตอนและระยะเวลาในการพัฒนา

26. เขียนโครงการตามขั้นตอนมาตรฐานเขียนโครงการตามขั้นตอนมาตรฐาน • ในการนิยามเนื้องาน ควรนิยามตามชนิดงานมาตรฐานที่สามารถใช้ได้กับทุกโครงการ เพราะจะช่วยให้ทำงานได้เร็ว และทุกคนเข้าใจง่าย • อาจนำซอฟต์แวร์ประเภท กรุ๊ปแวร์(Group ware) มาใช้ช่วยก็ได้ เพื่อให้ทีมพัฒนาสามารถเห็นความคืบหน้าของโครงการเหมือน ๆ กัน • นิยามทรัพยากรที่ต้องใช้ เช่น อุปกรณ์ เครื่องมือช่วย(Tool) คน เวลา แล้วนำมาคำนวณเป็นค่าใช้จ่าย

27. ขออนุมัติหลักการ โครงการ นิยาม เนื้องาน • วางแผนการทำงาน • กำหนดขั้นตอน • ประเมินแมนเดย์ • ประเมินระยะเวลา เขียนรายละเอียด ของโครงการ นิยามขอบเขต เขียน กำหนดการ ประเมิน ค่าใช้จ่าย นิยามทรัพยากร เขียนโครงการตามขั้นตอนมาตรฐาน(ต่อ) เขียนโครงการ

28. ค่อย ๆ ทบทวน แล้วเพิ่มรายละเอียด • ในการทำโครงการพัฒนา โครงการไม่ได้เขียนขึ้นมาทั้งหมดตั้งแต่ตอนแรก • ในขั้นตอนแรกเขียนโครงการแบบหยาบก่อน เมื่อเข้าสู่ขั้นตอนถัดไป จะมีการทบทวนโครงการและเขียนโครงการที่มีรายละเอียดมากขึ้น • เมื่อเริ่มโครงการ จะทำโครงการเวอร์ชันแรกก่อนเพื่อขออนุมัติทำโครงการ (ซึ่งจะยังไม่มีแผนปฏิบัติการ (Action Plan) จะเขียนหลังจากโครงการได้รับอนุมัติแล้ว)

29. ค่อย ๆ ทบทวน แล้วเพิ่มรายละเอียด(ต่อ) • Project Manager มีหน้าที่เขียนแผนปฏิบัติการ โดยในแผนจะดึงเอาความสามารถของลูกทีมออกใช้ประโยชน์ให้มากที่สุด • แผนปฏิบัติการถือเป็นแผนหลัก (Master Plan) ที่เขียนจากการมองภาพรวมของโครงการทั้งหมด แล้ววางแผนอย่างละเอียดเกี่ยวกับการนิยามความต้องการ

30. ค่อย ๆ ทบทวน แล้วเพิ่มรายละเอียด(ต่อ) โครงการ เขียน โครงการ นิยามความต้องการ ประเด็นในการออกแบบ ประเด็นในการพัฒนา ประเด็นในการโอนย้ายระบบ • ในการนิยามความต้องการ ต้องคุยรายละเอียดกับผู้ใช้ให้มากขึ้น • หลังนิยามความต้องการเสร็จ อาจพบว่าขอบเขตของงานที่จะต้องทำแตกต่างจากที่เคยวางแผนไว้ในตอนขออนุมัติ • เช่น ขอบเขตเพิ่มมากขึ้น เปลี่ยนแปลงไป หรือต้องปรับสถาปัตยกรรมของระบบงานบางส่วน เป็นต้น โครงการ ทบทวนโครงการแล้วเพิ่มรายละเอียด ทบทวนโครงการแล้วเพิ่มรายละเอียด

31. ค่อย ๆ ทบทวน แล้วเพิ่มรายละเอียด(ต่อ) โครงการ เขียน โครงการ นิยามความต้องการ ประเด็นในการออกแบบ ประเด็นในการพัฒนา ประเด็นในการโอนย้ายระบบ • ในการออกแบบก็จะต้องลงรายละเอียดเพิ่มขึ้น • เมื่ออกแบบเสร็จ ก็ต้องพิจารณาดูว่าจะต้องปรับแผนใหม่หรือไม่ เพราะเมื่อออกแบบเสร็จ จะเห็นรายละเอียดของแต่ละขั้นตอนในการพัฒนา ทำให้สามารถตัดสินเลือกวิธีการพัฒนาใหม่ที่ดีกว่า หรือจัดลำดับการทำงานใหม่ได้ โครงการ ทบทวนโครงการแล้วเพิ่มรายละเอียด ทบทวนโครงการแล้วเพิ่มรายละเอียด

32. การใช้ซอฟต์แวร์ช่วยบริหารโครงการการใช้ซอฟต์แวร์ช่วยบริหารโครงการ • โครงการพัฒนาซอฟต์แวร์ยิ่งมีขนาดใหญ่ ยิ่งต้องเกี่ยวข้องกับผู้คนจำนวนมาก และมีรายละเอียดมาก ทำให้มองภาพรวมได้ยาก รวมทั้งการติดตามความคืบหน้าในแต่ละขั้นตอน และการแจ้งความคืบหน้าให้ผู้ที่เกี่ยวข้องทำได้ยาก • ในการแก้ปัญหานี้คือ การนำเอาซอฟต์แวร์บริหารโครงการมาใช้ เช่น Microsoft Project มีจุดเด่นคือ ง่ายต่อการดูความคืบหน้าของโครงการ เช่น ดูแบบแกนต์ชาร์ต ดูแบบPERT และสามารถนำ output ไปแสดงใน MS Office ได้

33. เทคนิคในการประเมินราคาซอฟต์แวร์เทคนิคในการประเมินราคาซอฟต์แวร์ • การประเมินราคาซอฟต์แวร์ หมายถึง การประเมินจำนวนคนและระยะเวลาที่ต้องใช้ในการพัฒนาซอฟต์แวร์ หรือการประเมินจำนวน “แมนเดย์(Manday)”ที่จะใช้ในการพัฒนาซอฟต์แวร์ • การประเมินราคาซอฟต์แวร์ต้องใช้ ศาสตร์และความรู้สึกที่ต้องอาศัยประสบการณ์ สัญชาตญาณ และความอดทน

34. ขั้นตอนการประเมินแมนเดย์ขั้นตอนการประเมินแมนเดย์ เริ่มจาก • ระบุให้ชัดเจนว่า โครงการจะทำอะไร มีเงื่อนไขอย่างไร • คำนวณขนาดของซอฟต์แวร์ที่จะพัฒนา • แล้วจึงแปลงออกเป็นจำนวนแมนเดย์ในการพัฒนา

35. ขั้นตอนการประเมินแมนเดย์(ต่อ)ขั้นตอนการประเมินแมนเดย์(ต่อ) • จุดเด่นของโครงการ • ซอฟต์แวร์หรือฮาร์ดแวร์ที่ใช้ในการพัฒนา • กระบวนการทำงานที่จะนำซอฟต์แวร์ไปใช้ • คนที่เกี่ยวข้องกับโครงการ ประเมินขนาดของซอฟต์แวร์ ประเมิน แมนเดย์ที่ใช้ เงื่อนไขของระบบ ตัวแปรที่มีผลกระทบ

36. ขั้นตอนการประเมินแมนเดย์(ต่อ)ขั้นตอนการประเมินแมนเดย์(ต่อ) • หลังประเมินขนาดซอฟต์แวร์เสร็จ ก็ต้องแปลงขนาดของซอฟต์แวร์ให้เป็นจำนวนแมนเดย์ที่ใช้ในการพัฒนา • ตัวแปรที่มีผลกระทบต่อแมนเดย์คือ ภาษา หรือวิธีที่ใช้ในการพัฒนา ความยากง่ายของโครงการโดยรวม ประสิทธิภาพของทีมพัฒนาซอฟต์แวร์

37. วิธีการประเมินราคาซอฟต์แวร์แบบหลัก ๆ

38. วิธีการประเมินราคาซอฟต์แวร์แบบหลัก ๆ

39. การประเมินแบบคร่าว ๆ • เป็นการประเมินราคาตอนต้นโครงการ • นิยมนำโครงการก่อนหน้าที่คล้ายกันมาเปรียบเทียบ แล้วประเมินแมนเดย์หรือค่าใช้จ่ายออกมา • โครงการก่อนหน้าที่นำมาอ้างอิง ควรมีความคล้ายคลึงกันหลายแง่ เช่น ขอบเขตของระบบงาน ฟังก์ชันของระบบงาน กระบวนการพัฒนา ภาษาที่ใช้ในการพัฒนา ฯลฯ • ความละเอียดหรือความแม่นยำในการประเมินต่ำ • แต่หาผู้ทำการประเมินเคยมีส่วนร่วมในโครงการก่อนหน้า และมีการจัดเก็บข้อมูลไว้อย่างดี วิธีนี้จะเป็นการประเมินที่ใช้ค่าใช้จ่ายต่ำสุด แต่ให้ผลลัพธ์น่าเชื่อถือสุด

40. การประเมินแบบรวมแมนเดย์ของงานย่อยการประเมินแบบรวมแมนเดย์ของงานย่อย • แบ่งงานออกเป็นงานย่อย จนสามารถทราบแมนเดย์ของงานย่อยได้ • จากนั้นก็นำเอาแมนเดย์ของงานย่อยมารวมกันเป็นแมนเดย์ของโครงการ • ความแม่นยำของวิธีนี้ขึ้นอยู่กับ ความละเอียดในการแบ่งงานย่อย • หากแบ่งงานย่อยได้ละเอียด ความแม่นยำในการประเมินก็จะสูงขึ้น แต่ก็ต้องเสียค่าใช้จ่ายในการประเมินสูงตามด้วย(เนื่องจากมีปริมาณงานมาก)

41. ตัวอย่างการประเมินแบบแบ่งงานย่อยตัวอย่างการประเมินแบบแบ่งงานย่อย Manday รวม = ax + by + cz + …

42. การประเมินแบบรวมแมนเดย์ของงานมาตรฐานการประเมินแบบรวมแมนเดย์ของงานมาตรฐาน • เป็นการปรับปรุงจากการประเมินแมนเดย์ของงานย่อย • การประเมินแบบงานมาตรฐาน คือ การแบ่งงานในการพัฒนาทั้งหมดออกเป็นกลุ่มของงานมาตรฐาน (Task) • งานมาตรฐานต้องถูกนิยามล่วงหน้าในตารางงานมาตรฐาน โดยต้องระบุแมนเดย์ที่ใช้ โดยคำนวณจากผลของทีมงานในโครงการที่ผ่านมา • จากนั้นทำการแบ่งโครงการออกเป็นงานย่อย และทำการจับคู่ (Map) งานย่อยกับงานมาตรฐาน • ทำให้ทราบว่าในแต่ละงานมาตรฐานมีงานย่อยที่ต้องทำอะไรบ้าง ทำให้สามารถประเมินแมนเดย์ของโครงการได้อย่างแม่นยำ

43. ตัวอย่างการประเมินแบบงานมาตรฐานตัวอย่างการประเมินแบบงานมาตรฐาน ตารางงานมาตรฐาน แมนเดย์ที่ใช้ในการออกแบบหน้าจอ ,  , … แมนเดย์ต่อชิ้นงาน ความต้องการของโครงการ A, B , … แมนเดย์ต่อชิ้นงาน

44. COCOMO • COCOMO (Constructive COSt MOdel) ถูกเสนอโดย Dr. BarryBoehm ในปี 1981 • คำนวณขนาดของโครงการพัฒนาระบบโดยการใช้การนับจำนวนบรรทัดของSource code (LOC : Line Of Code) แล้วแปลงออกมาเป็นแมนเดย์ที่ต้องใช้ • เหมาะกับโครงการที่มี Source code หลายหมื่นหลายแสนบรรทัด

45. COCOMO • COCOMO แบ่งออกเป็น 3 เวอร์ชันย่อย ได้แก่ • Basic COCOMO สำหรับใช้ประเมินตอนต้นโครงการ • Middle COCOMO สำหรับใช้ประเมินหลังจบการนิยามความต้องการ • Detail COCOMO สำหรับใช้ประเมินหลังออกแบบเสร็จ

46. การประเมินแบบ Function Point (FP) • วัดขนาดซอฟต์แวร์ด้วยการนับฟังก์ชันในการทำงาน • แล้วแปลงออกมาเป็นคะแนน (Point) • โดยฟังก์ชันถูกนิยามเป็น Input ออกหน้าจอ และOutput ออกรายงาน การใช้ไฟล์ อินเทอร์เฟสกับภายนอก ฯลฯ