Transcript การบริหารโครงการ - ผศ.วิวัฒน์ ชินนาทศิริกุล

การเขียนโครงการและการบริหาร
โครงการ
อ.วิวฒ
ั น์ ชินนาทศิริกุล
ความสาคัญของการเขียนโครงการ



เป็ นการเขียนแผนพัฒนาโครงการขึ้นล่วงหน้า และพยายามควบคุมให้
งานคืบหน้าตามแผนที่กาหนด
ในโครงการพัฒนาซอฟแวร์ จุดเริ่มต้นเป็ นส่วนที่สาคัญที่สุด ซึ่งเป็ นการทา
ความเข้าใจขอบเขตและรายละเอียดของโครงการ แล้วประเมินค่าใช้จ่าย
การเขียนโครงการก่อนเริ่มพัฒนา เป็ นการบังคับให้เรามีการวิเคราะห์และ
ตรวจสอบเป้าหมาย และรายละเอียดสิ่งที่ตอ้ งทาอย่างจริงจัง ทาให้มี
โอกาสทบทวนปั ญหา ความเสี่ยงที่อาจเกิดขึ้ น และเตรียมพร้อมรับมือไว้
ล่วงหน้า

แผนในการพัฒนาโครงการ มีไว้เพื่อถ่ายทอดให้กบั สมาชิกของโครงการ
และเป็ นการกาหนดนโยบายว่า ต้องทาอะไร ให้เสร็จภายในระยะเวลา
เท่าไร ทาให้สมาชิกในโครงการทางานในส่วนของตนได้อย่างอิสระ
สรุป ความสาคัญของการเขียนโครงการ





กาหนดเป้าหมาย ขอบเขตการทางานของซอฟแวร์ เนื้ องาน และ
ทีมงาน
ทบทวนความเสี่ยง และปั ญหาที่อาจเกิดขึ้ น
เป็ นนโยบายในการทางานของสมาชิกโครงการ
ทาให้สมาชิกแต่ละคนทางานได้ราบรื่น
ช่วยให้ผจู้ ดั การโครงการแสดงภาวะผูน้ า
การบริหารโครงการ


เป็ นการติดตามว่าโครงการคืบหน้าแค่ไหน ติดปั ญหาอะไรบ้าง และ
จัดการทรัพยากรให้โครงการสาเร็จตามเป้าหมาย ภายใต้ระยะเวลา
และงบประมาณที่มี การบริหารโครงการจึงเป็ นสิ่งที่ขาดไม่ได้ในการทา
โครงการ
ในการบริหารโครงการ ต้องเข้าใจสถานการณ์ของโครงการ ทั้งในแง่ของ
ค่าใช้จ่าย ระดับความคืบหน้า คุณภาพของงาน ต้องทารายงานให้
ผูเ้ กี่ยวข้อง มองเห็นและเข้าใจได้ทนั ที ว่าตอนนี้ โครงการมีความคืบหน้า
อย่าไร หากโครงการไม่คืบหน้าตามแผน แสดงว่ามีปัญหาเกิดขึ้ น ผูจ้ ดั การ
โครงการจะต้องค้นหาสาเหตุและกาหนดมาตรการแก้ไข
สรุป ความสาคัญในการบริหารโครงการ




ช่วยให้เข้าใจความคืบหน้า และการใช้งบประมาณ
ทาให้ผเู้ กี่ยวข้องที่ได้รบั ผลกระทบเข้าใจได้ทนั ทีวา่ โครงการมีความ
คืบหน้าอย่างไร
ทาให้เห็นปั ญหาจากการดูวา่ ความคืบหน้า เป็ นไปตามแผนหรือไม่
ช่วยให้วิเคราะห์และกาหนดมาตรการ แก้ไขปั ญหาได้ถูกต้อง
ภาพรวมในการเขียนโครงการ

กล่าวกันว่า ในการพัฒนาซอฟแวร์ สิ่งที่เราต้องควบคุมคือ QCD ได้แก่
1. Quality
2. Cost
3. Delivery
สื่งเหล่านี้ ถือเป็ นหัวข้อสาคัญในการเขียนโครงการ

นอกจากนี้ ยังมีสิ่งที่ตอ้ งพิจารณาหลายอย่าง ดังภาพ
ประเด็นที่ตอ้ งพิจารณา
รายละเอียด
 ตัวโครงการ
ขอบเขต กาหนดการ คุณภาพ ความเสี่ยง ฯลฯ
 สายงานและคน
สายงานบังคับบัญชา การฝึ กอบรม การสื่อสาร
ฯลฯ
 การจัดซื้ อจัดหา
Supplier
ระยะเวลาในการส่งมอบ คุณภาพ
ราคา
 ค่าใช้จา่ ยในการพัฒนา
ค่าจ้าง ค่าอุปกรณ์ ค่าใช้จา่ ยในการบริหาร ฯลฯ
 เครื่องมือในการพัฒนา
ฮาร์ดแวร์ ซอฟต์แวร์ ฯลฯ

หน่ วยงาน Project Management Institute ของอเมริกา ได้กาหนดว่า
ในการบริหารโครงการหรือ Project Management มี 9 เรื่องที่ควร
พิจารณา ได้แก่
1. การบริหารภาพรวม (Total Management)
2. การบริหารขอบเขต (Scope Management)
3. การบริหารเวลา (Time Management)
4. การบริหารค่าใช้จา่ ย (Cost Management)
5. การบริหารคุณภาพ (Quality Management)
6. การบริหารองค์กร (Organization Management)
7. การบริหารการสื่อสาร (Communication Management)
8. การบริหารอุปทาน (Supply Management)
9. การบริหารความเสี่ยง (Risk Management)
การเขียนโครงการและการบริหารโครงการ
นิยามขอบเขต
วางแผนและบริหารขอบเขต
บริหารการเปลี่ยนแปลง
บริหารผลลัพธ์
นิยามงานย่อย
เขียน
โครงการ
และ
บริหาร
โครงการ
วางแผนและบริหารกาหนดการ
บริหารกาหนดการ
การนิยามขอบเขต
วางแผนคุณภาพ
วางแผนและบริหารคุณภาพ
ประกันคุณภาพ
บริหารคุณภาพ
ระบุความเสี่ยง
วางแผนและบริหารความเสี่ยง
กาหนดมาตรการรองรับความเสี่ยง
บริหารความเสี่ยง
การวางแผนและบริหารขอบเขต


พิจารณาดูแผนงานของโครงการว่ามีขอบเขตแค่ไหน ขอบเขตถูกกาหนด
ขึ้ นตามความต้องการหรือความคาดหวังของลูกค้า จึงเป็ นขอบเขตที่ลกู ค้า
ตกลงกับผูพ้ ฒ
ั นาว่า ขอบเขตการใช้งานซอฟแวร์คืออะไร ซอฟแวร์ทาอะไร
ได้บา้ ง เรียกขั้นตอนนี้ ว่า การบริหารขอบเขต (Scope Planning)
การบริหารขอบเขตครอบคลุม การบริหารความเปลี่ยนแปลง ซึ่งเป็ น
การพยายามรักษาคุณภาพร่วมกับลูกค้า ในกรณีที่ลกู ค้าเปลี่ยนแปลง
ความต้องการในขั้นตอนการออกแบบหรือพัฒนา หรือในกรณีที่ผูพ้ ฒ
ั นา
ร้องขอลูกค้าให้เปลี่ยนแปลงสเปกของโปรแกรมเพื่อแก้ปัญหาหรือจัดการ
ความเสี่ยงบางอย่าง เพื่อให้งานสามารถเดินหน้าต่อไปด้วยดี


การวางแผนและบริหารขอบเขต ยังรวมไปถึงการนิ ยามสิ่งที่เกิดขึ้ นจาก
โครงการและการบริหารสิ่งที่เกิดขึ้ น เช่น ตัวโปรแกรม เอกสารการ
ออกแบบ คู่มือการใช้งาน
สิ่งที่เกิดขึ้ นที่ตอ้ งบริหาร ไม่ได้จากัดเพียงแค่ชิ้นงานสุดท้ายที่ส่งมอบให้
ลูกค้าเท่านั้น ยังรวมไปถึงสิ่งต่างๆที่เกิดขึ้ นในระหว่างโครงการ
ภาพแสดงการวางแผนและบริหารขอบเขต
การวางแผนและ
บริหารขอบเขต
นิยามขอบเขต
บริหารการเปลี่ยนแปลง
บริหารผลลัพธ์
ผลลัพธ์ระหว่างการพัฒนา
ผลลัพธ์สุดท้าย
การวางแผนและบริหารกาหนดการ



เป็ นการกาหนดว่า เมื่อไร จะส่งมอบงานให้ลกู ค้า เมื่อไรจะโอนย้าย
ระบบงานเก่ามาระบบใหม่ โดยทัว่ ไปลูกค้าจะเป็ นคนตัดสินใจขั้นสุดท้าย
ว่าวันไหนเหมาะสม
ผูบ้ ริหารโครงการ ต้องควบคุมงานพัฒนา ให้เดินหน้าทันเวลานัดส่งมอบ
งาน ดังนั้นจึงต้องมองเห็นเนื้ องานที่ตอ้ งทาทั้งหมด ตั้งแต่ข้นั ตอนการ
วางแผน ต้องนิ ยามงานแต่ละชิ้ นที่ตอ้ งทาตามขอบเขต และผลลัพธ์ที่นิยาม
ในขั้นตอนการวางแผนและบริหารขอบเขต
การนิ ยามงานคือ การนิ ยามความต้องการของลูกค้า การออกแบบ และ
การจัดสรรทรัพยากร


งานออกแบบ ต้องทาทั้งการออกแบบภายนอก ซึ่งเป็ นการออกแบบ
อินเทอร์เฟส สาหรับลูกค้าใช้งาน กับการออกแบบภายใน สาหรับใช้เขียน
โปรแกรม เมื่อออกแบบครบก็จะเห็นภาพรวมของโครงการ
ในขั้นตอนนี้ ไม่จาเป็ นต้องนิ ยามงานทั้งหมดอย่างละเอียด การนิ ยาม
รายละเอียดของเนื้ องาน อาจค่อยๆทาทีหลัง แต่ให้เสร็จก่อนเริม่ งานนั้น

การนิ ยามเนื้ องานแบบนี้ เรียกว่า WBS (Work Breakdown Structure)
โดยการแบ่งงานย่อยไปเรื่อยๆ จนกว่าจะได้งานย่อยที่ใช้เวลาไม่เกิน 1 สัปดาห์
การพัฒนา
ซอฟต์แวร์
นิยามความ
ต้องการ
ออกแบบ
พัฒนา
ทดสอบการ
อิทิเกรต
บริหาร
โครงการ
วิเคราะห์การ
ทางานเดิม
ออกแบบ
ภายนอก
เขียนโปรแกรม
ทดสอบการ
อินทิเกรต
บริหารความ
เปลี่ยนแปลง
วิเคราะห์ความ
ต้องการ
ออกแบบภายใน
ทดสอบโมดูล
ทดลองใช้งาน
บริหารค่าใช้จา่ ย
ความต้องการ
ซอฟต์แวร์
...
บริหารอุปทาน



เมื่อแบ่งงานย่อยออกมา จะทาให้เห็นภาพรวมของงานทั้งหมดที่ตอ้ งทาได้
อย่างครบถ้วน จากนั้นจะดูวา่ งานไหนต้องทาก่อนทาหลัง หรืองานไหน
ต้องรอให้อีกงานหนึ่ งเสร็จก่อน แล้วจัดเวลาทางานย่อยแต่ละชิ้ นออกมา
เมื่อได้เวลาทางานย่อยแล้ว จึงเขียนสรุปกาหนดการในโครงการใน
ภาพรวม
เมื่อจัดการกาหนดการได้ การควบคุมความคืบหน้าของโครงการก็งา่ ยขึ้ น
โดยติดตามดูวา่ งานย่อยแต่ละงานคืบหน้าตามกาหนดหรือไม่ ทาให้เข้า
ใจความคืบหน้าของโครงการได้อย่างถูกต้อง
ในแต่ละงานย่อย จะต้องระบุปริมาณงาน (จานวนคนที่ใช้) วันเริ่มต้น วัน
สิ้ นสุดของชัดเจนเป็ นตัวเลข
การวางแผนและบริหารคุณภาพ

ต้องควบคุม ให้งานที่ออกมาตรงกับความต้องการของลูกค้า ลูกค้ามีความ
พึงพอใจ ซอฟแวร์ไม่มีปัญหาทางเทคนิ ค
การบริหารความเสี่ยง

ความเสี่ยงที่เกิดขึ้ นในการพัฒนาซอฟแวร์ คือ สิ่งที่อาจมีผลทาให้โครงการ
พัฒนาซอฟแวร์ไม่ประสบความสาเร็จ ความเสี่ยงที่พบทัว่ ไป ได้แก่
- โครงการที่มีขนาดใหญ่ และมีความซับซ้อน
- ความคลาดเคลื่อนในการเสนอราคา
- ความเปลี่ยนแปลงด้านความต้องการ
- ความผิดพลาดในการออกแบบ
- การขาดทักษะด้านเทคนิ ค หรือขาดความรูด้ า้ นวิธีการทางานของลูกค้า
- การใช้ฮาร์ดแวร์ หรือซอฟแวร์ใหม่


เราต้องมีการระบุความเสี่ยง (Risk Identification) ล่วงหน้า
จากนั้นก็เตรียมมาตรการรองรับเพื่อป้องกันความเสี่ยง หรือควบคุม
ผลกระทบที่อาจเกิดขึ้ นจากความเสี่ยงนั้น
การเตรียมตัวไว้ก่อนจะช่วยให้ความเสี่ยง ส่งผลกระทบน้อยในระดับที่รบั
ได้ ซึ่มีประสิทธิภาพมากกว่า การรอให้เกิดปั ญหาขึ้ นมาก่อน แล้วจึงคิด
หาทางแก้ไข
ตัวอย่างเทคนิค การจัดทา Schedule
1. Network Diagram
เป็ นวิธีที่นางานมาเชื่อมต่อกันแบบเครือข่าย การใช้ลกู ศรแสดงให้เห็นว่า
งานหนึ่ งต้องเสร็จก่อน จึงจะเริ่มอีกงานหนึ่ งได้ ทาให้มองเห็น ถ้างานใด
งานหนึ่ งล่าช้า จะส่งผลกระทบอย่างไรบ้าว อาจเรียกวิธีนี้ว่า Program
Evaluation and Review Technique (PERT)
A2
A1
A4
A5
A6
C1
A3
B
C2
C3
2.
แกนต์ชาร์ต (Gant Chart หรือ Bar Chart)
แกนต์ชาร์ต ใช้แกนตั้งเป็ นงานแต่ละชิ้ นที่จะต้องทา แกนนอนแสดงเวลา
ใช้กราฟแท่งในแนวนอน แสดงเวลาในการทางานแต่ละชิ้ น
เป็ นวิธีที่นิยมใช้กนั มากในโครงการทัว่ ๆไป เพราะเห็นชัดเจนว่างานแต่
ละชิ้ น ต้องเริ่มเมื่อไร และต้องเสร็จเมื่อไร
แต่ก็แตกต่างจาก Network Diagram ตรงที่ไม่ทราบว่างานแต่ละชิ้ นมี
ความสัมพันธ์กบั งานอื่นอย่างไร
รูปแสดงแกนต์ชาร์ต
การวางแผนและการบริหารคน



การบริหารคนไม่ให้เกิดปั ญหา เป็ นสิ่งสาคัญที่สุดในการบริหารโครงการ
เริ่มจากการเตรียมทีมงานรองรับตามขนาดของงานที่ประเมินไว้
การวางแผนการสื่อสาร เช่นต้องมีการติดต่อสื่อสาร ประสานงานกับใคร
บ้าง ต้องมีการจัดเอกสารอะไรและส่งให้ใครบ้าง
โครงสร้างทีมงานในการพัฒนา
ในการพัฒนามีบุคคล 2 กลุ่มเข้ามาเกี่ยวข้อง ได้แก่
1. ผูใ้ ช้ซอฟแวร์
2. หน่ วยงานด้านสารสนเทศที่รบั ผิดชอบในการพัฒนาซอฟแวร์
 หน่ วยงานด้านสารสนเทศ อาจพัฒนาซอฟแวร์เอง หรือประสานงานจ้างบริษัท
ภายนอกมาช่วยพัฒนา
 กรณีที่หน่ วยงานด้านสารสนเทศพัฒนาซอฟแวร์เอง หน่ วยงานสารสนเทศสามารถจัด
ทีมงาน และโครงสร้างการทางานเองได้
 กรณีจา้ งบริษัทภายนอกมาพัฒนา หน่ วยงานสารสนเทศ จะเป็ นตัวกลาง ในการ
ประสานงานระหว่างผูใ้ ช้ในบริษัท กับ บริษัทซอฟแวร์ และมีหน้าที่หลักในการสรุป
รวบรวมความต้องการภายในบริษัทแจ้งแก่ทีมงานพัฒนา ติดตามความคืบหน้าและ
ตรวจรับ

โครงสร้างทีมงานในการพัฒนา (ต่อ)

ทีมงานในการพัฒนาซอฟแวร์ ประกอบด้วย
1. โปรเจกต์เมเนเจอร์ (Project Manager) หรือผูจ้ ดั การโครงการ มี
หน้าที่รบั ผิดชอบโครงการพัฒนาทั้งหมด
2. โปรเจกต์ลีดเดอร์ (Project Leader) หรือหัวหน้าทีมย่อย ซึ่งมักเป็ น
ระดับนักวิเคราะห์ระบบ
3. โปรแกรมเมอร์ (Programmer)



ในการพัฒนาซอฟแวร์ขนาดเล็ก หรือโพรโตไทป์ โปรเจกต์ลีดเดอร์ อาจต้อง
เขียนโปรแกรมเอง จานวนทีมย่อยหรือจานวนคนในโครงการขึ้ นอยูก่ บั ขนาด
ของโครงการนั้นๆ ทีมงานจะมีหน้าที่ในการออกแบบและพัฒนา โดย
ประสานงานกับกลุ่มผูใ้ ช้ในการรวบรวมความต้องการ และทาการทดสอบก่อน
ใช้งานจริง
หลายๆโครงการนิ ยมตั้ง โปรเจกต์สตาฟขึ้ นมา เพื่อทาหน้าที่สนับสนุ นการ
ทางานของโปรเจกต์ลีดเดอร์ทุกคน ทั้งในแง่ของการเตรียมข้อมูล หรืออุปกรณ์
ในการพัฒนา การกาหนดขั้นตอนมาตรฐาน หรือเอกสารมาตรฐานให้ทุกๆทีม
ทาเหมือนกัน
หากโครงการมีขนาดใหญ่ขึ้น อาจมีโปรเจกต์สตาฟท์ ที่ทาหน้าที่ช่วยโปรเจกต์
เมเนเจอร์ ในการติดตามความคืบหน้าของโครงการ ช่วยแก้ไขปั ญหาที่เกิดขึ้ น
ช่วยบริหารความเปลี่ยนแปลง และช่วยงานด้านเอกสารหรือธุรการ
บริษัทที่ตอ้ งการใช้ซอฟต์แวร์
ทีมงานพัฒนา
Project Manager
(1 คน)
กลุ่มผูใ้ ช้ซอฟต์แวร์
(End User)
Project Staff
(0-2 คน)
หน่ วยงานด้านสารสนเทศ
โครงสร้างทีมงาน
ในการพัฒนา
ซอฟแวร์
Project Leader
(1 คน)
Programmer
(หลายคน)
Project Leader
(1 คน)
Programmer
(หลายคน)
Project Leader
(1 คน)
Programmer
(หลายคน)
การวางแผนและบริหารอุปทาน



ในการพัฒนาซอฟต์แวร์บางครั้งต้องมีการใช้ sub-contract (บริษัทอื่น
มารับงานบางช่วง) มาช่วยงานด้วย
ในการบริหาร sub-contract ต้องระมัดระวังเรื่องเวลาในการส่งมอบงาน
คุณภาพและค่าใช้จ่าย
การบริหารอุปทานยังรวมถึง การบริหาร supplier ที่ขายสินค้าต่าง ๆ ให้
เรา เช่น software package , tools ในการพัฒนา หรือ Hardware
ต่าง ๆ
การวางแผนและการบริหารค่าใช้จา่ ยในการพัฒนา

ค่าใช้จ่ายในการพัฒนา ประกอบด้วย
1. ค่าใช้จา่ ยทางตรง เช่น ค่าจ้างพนักงาน ค่าจ้าง sub contract
2. ค่าใช้จา่ ยทางอ้อม เช่น ค่าใช้จา่ ยด้านอุปกรณ์ และด้านธุรการ เช่น ค่า โทรศัพท์
ค่ารถ ฯลฯ

จาเป็ นต้องวางแผนและบริหารค่าใช้จ่ายเป็ นรายเดือน แยกออกมาเป็ น
หัวข้อให้ชดั เจน ในการพัฒนาซอฟแวร์ค่าใช้จ่ายส่วนใหญ่ เป็ นค่าใช้จ่าย
ทางตรง ในการจ้างพนักงาน หรือ sub contract ต้องคานวณค่าใช้จ่าย
จากการปะเมินปริมาณงานที่ตอ้ งทา
การประเมินปริมาณงาน



นิ ยมคานวณเป็ น แมนเดย์ (ManDay)
หมายถึง จานวนคน คูณ จานวนวันที่ตอ้ งใช้ในการทางาน
หากประเมินปริมาณงานคลาดเคลื่อน นอกจากจะทาให้คานวณค่าใช้จ่าย
ได้ไม่ถูกต้องแล้วยังทาให้ การวางแผนด้านต่างๆผิดพลาด เช่น จานวนคน
ที่ตอ้ งใช้ ระยะเวลาในการส่งมอบ ฯลฯ ซึ่งหากเกิดข้อผิดพลาดมากๆอาจ
ทาให้โครงการประสบความล้มเหลวได้
รูปแสดงค่าใช้จ่ายในการพัฒนา
การวางแผนและบริหารสิ่งแวดล้อมในการพัฒนา



ปกติผพู้ ฒ
ั นาซอฟต์แวร์จะเป็ นผูร้ บั ผิดชอบเตรียมสิ่งแวดล้อมในการทางาน
เอง เช่น เครื่องคอมพิวเตอร์ ซอฟต์แวร์ tools ต่าง ๆ
แต่บางกรณีลกู ค้าก็จะเป็ นผูจ้ ดั หามาให้
ผูพ้ ฒ
ั นาต้องเตรียมค่าใช้จ่ายเผื่อไว้ เป็ นค่าสิ่งแวดล้อมในการพัฒนา
ตลอดจนค่าฝึ กอบรมหรือวิจยั ในส่วนของเทคโนโลยีใหม่
เอกสารโครงการ
เนื้ อหาของเอกสารของโครงการ ประกอบด้วย
 เป้าหมายและวัตถุประสงค์ของโครงการ ขอบเขต สมมติฐาน
 แผนบริหารโครงการ(แผนคุณภาพ แผนค่าใช้จ่าย แผนจัดการปั ญหา แผน
บริหารความเสี่ยง แผนการสื่อสาร แผนการทบทวน)
 เอาต์พุตของโครงการ(สิ่งที่ตอ
้ งส่งมอบ วันที่ส่ง สื่อที่ใช้)
 แผนบริหารทีมงาน(โครงสร้างทีมงาน จานวนคนที่ตอ
้ งการในแต่ละเดือน
แผนการฝึ กอบรม)
 แผนเกี่ยวกับเนื้ องานและกาหนดการ(WBS การระดมสมอง กาหนดการ
ทางาน)
 แผนบริหารอุปทาน(เอาต์พุตที่ตอ
้ งการ เวลาตรวจรับงาน วันชาระเงิน)
ประเด็นในการเขียนโครงการ

ในการวางแผนการดาเนิ นการตามโครงการจริง ต้องดาเนิ นการดังนี้
1. เริ่มจากศึกษาความต้องการและขอบเขต แล้วประเมินขนาดของโครงการ
แผนการต้องระบุให้ชดั เจนว่าจะต้องทาอะไร ในการพัฒนาซอฟแวร์จุดเริ่มต้นคือ
ความต้องการ ความคาดหวังของลูกค้า
ต้องศึกษาให้รวู ้ า่ เป้าหมายหรือวัตถุประสงค์ของการพัฒนาซอฟแวร์ที่ได้รบั
มอบหมายคืออะไร ขอบเขตของระบบงานที่นาซอฟแวร์ไปใช้มีแค่ไหน หลังจากนา
ซอฟแวร์ไปใข้แล้ว มีวธิ ีการทางานแบบใหม่อย่างไร ฯลฯ เหล่านี้ คือ การนิ ยาม
ขอบเขตของโครงการ
จากนั้นต้องประเมินขนาดของโครงการ เลือกวิธีการพัฒนา สรุปขั้นตอนและ
ระยะเวลาในการพัฒนา
รูป แสดงขั้นตอนการเขียนโครงการ
2. เขียนโครงการตามขั้นตอนมาตรฐาน
แม้โครงการพัฒนาซอฟแวร์แต่ละโครงการมีรายละเอียดต่างกัน แต่ควรใช้ข้นั ตอนมาตรฐาน
ในการเขียนโครงการ ดังภาพ
3.
ค่อยๆทบทวนแล้วเพิ่มรายละเอียด
การทาโครงการพัฒนาซอฟแวร์ โครงการไม่ได้ถกู เขียนมาทั้งหมดตั้งแต่เริ่มแรก ใน
ขั้นตอนแรกจะเขียนโครงการที่หยาบก่อน เมื่อเข้าสู่ข้นั ตอนถัดไป จะมีการทบทวน
โครงการและเขียนโครงการที่มีรายละเอียดมากขึ้ น ดังภาพ



เมื่อเริ่มโครงการ จะทาโครงการเวอร์ชนั ่ แรกเพื่อขอนุ มตั ิโครงการ จึงไม่มี
แผนปฏิบตั ิการ (Action Plan) ซึ่งมีเนื้ อหาละเอียดถึงระดับการทางาน
แผนปฏิบตั ิการจะถูกเขียนหลังโครงการอนุ มตั ิแล้ว
โปรเจกต์เมเนเจอร์ มีหน้าที่เขียยนแผนปฏิบตั ิการ ในแผนต้องดึงความรู ้
ความสามารถของลูกทีม มาใช้ประโยชน์ให้มากที่สุด แผนปฏิบตั ิการนี้ ถือเป็ น
แผนหลัก (Master Plan) ที่เขียนขึ้ นจากการมองภาพรวมของโครงการ
ทั้งหมด และเป็ นพื้ นฐานในการทาโครงการจริง
การนิ ยามความต้องการ ต้องคุยรายละเอียดกับผูใ้ ช้มากขึ้ น หลังนิ ยามความ
ต้องการเสร็จ อาจพบว่าขอบเขตของงานที่ตอ้ งทาแตกต่างจากที่เคยวางแผน
ไว้ตอนที่ขออนุ มตั ิ โปรเจกต์เมเนเจอร์สามารถตัดสินใจ ปรับแก้แผนได้โดยไม่
กระทบโครงการโดยรวม กรณีงานมีความแตกต่างกันมากเกินไป โปรเจกต์
เมเนเจอร์ อาจต้องขออนุ มตั ิแผนใหม่จากผูบ้ ริหารระดับสูง

ในการออกแบบก็จะต้องลงรายละเอียดเพิ่มเติม เมื่อออกแบบเสร็จ ก็ตอ้ ง
พิจารณาดูวา่ จาเป็ นต้องปรับแผนหรือไม่ เพราะเมื่อออกแบบเสร็จ จะเห็น
รายละเอียดของแต่ละขั้นตอนในการพัฒนา ทาให้สามารถตัดสินใจเลือก
วิธีการพัฒนาใหม่ที่ดีกว่า หรือจัดลาดับการทางานใหม่
แบบฝึ กหัด


ให้นักศึกษาหาข้อมูลทารายงาน เรื่อง การเขียนข่ายงานโครงการ(Project
Network Diagram)ด้วยเทคนิ ค PERT (Project Evaluation Review
and Technique) และ CPM (Critical Path Method)เป็ นอย่างไร และ
มีความแตกต่างกันอย่างไร และมีวธิ ีคานวณหาระยะเวลาในการทางาน
อย่างไร (งานเดี่ยว)
กาหนดส่งวันที่ 17 ตุลาคม 2553 ในเวลาเรียน
เอกสารอ้างอิง

เรื่องพัฒนาซอฟแวร์มีแค่นี้ แปลและเรียบเรียงโดย ดร.สมชาย กิตติชยั กุล
กิจ สานักพิมพ์ ส.ส.ท.