การจัดการโครงการซอฟต์แวร์

การจัดการโครงการซอฟต์แวร์คือกระบวนการวางแผนและนำโครงการซอฟต์แวร์^{[ 1 ]}เป็นสาขาย่อยของการจัดการโครงการซึ่งมีการวางแผน ดำเนินการ ตรวจสอบ และควบคุมโครงการ ซอฟต์แวร์

ในช่วงทศวรรษ 1970 และ 1980 อุตสาหกรรมซอฟต์แวร์เติบโตอย่างรวดเร็ว เนื่องจากบริษัทคอมพิวเตอร์ตระหนักได้อย่างรวดเร็วว่าต้นทุนการผลิตซอฟต์แวร์นั้นค่อนข้างต่ำเมื่อเทียบกับการผลิตฮาร์ดแวร์และวงจรไฟฟ้า เพื่อจัดการกับความพยายามในการพัฒนาใหม่ ๆ บริษัทต่าง ๆ ได้นำวิธีการบริหารจัดการโครงการที่มีอยู่มาใช้ แต่กำหนดการ ของโครงการ มักล่าช้าในระหว่างการทดสอบ โดยเฉพาะอย่างยิ่งเมื่อเกิดความสับสนในพื้นที่สีเทาระหว่างข้อกำหนดของผู้ใช้และซอฟต์แวร์ที่ส่งมอบ เพื่อหลีกเลี่ยงปัญหาเหล่านี้ วิธีการบริหารจัดการโครงการ ซอฟต์แวร์จึงมุ่งเน้นไปที่การจับคู่ความต้องการของผู้ใช้กับผลิตภัณฑ์ที่ส่งมอบ ซึ่งเป็นวิธีการที่รู้จักกันในปัจจุบันว่าโมเดลแบบน้ำตก (Waterfall model )

เมื่ออุตสาหกรรมเติบโตเต็มที่ การวิเคราะห์ความล้มเหลวในการจัดการโครงการซอฟต์แวร์แสดงให้เห็นว่าสาเหตุที่พบบ่อยที่สุดมีดังต่อไปนี้: ^{[ 2 ] [ 3 ] [ 4 ]}

1. การมีส่วนร่วมของผู้ใช้งานปลายทางไม่เพียงพอ
2. การสื่อสารที่ไม่ดีระหว่างลูกค้า นักพัฒนา ผู้ใช้ และผู้จัดการโครงการ
3. เป้าหมายโครงการที่ไม่สมจริงหรือไม่ชัดเจน
4. การประมาณการทรัพยากรที่ต้องการไม่ถูกต้อง
5. ข้อกำหนดและรายละเอียดของระบบที่กำหนดไว้ไม่ชัดเจนหรือไม่ครบถ้วน
6. การรายงานสถานะโครงการที่ไม่ดีพอ
7. ความเสี่ยงที่จัดการได้ไม่ดี
8. การใช้เทคโนโลยีที่ยังไม่สมบูรณ์
9. ไม่สามารถรับมือกับความซับซ้อนของโครงการได้
10. แนวทางการพัฒนาที่ไม่รอบคอบ
11. การเมือง ภายในกลุ่มผู้มีส่วนได้ส่วนเสีย (เช่น การขาดการสนับสนุนจากผู้บริหาร หรือความขัดแย้งทางการเมืองระหว่างลูกค้าและผู้ใช้งาน)
12. แรงกดดันทางการค้า

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

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

• การสื่อสารระหว่างบุคคล การจัดการ และการแก้ไขความขัดแย้งการสื่อสารที่กระตือรือร้น บ่อยครั้ง และตรงไปตรงมา เป็นปัจจัยสำคัญที่สุดในการเพิ่มโอกาสความสำเร็จของโครงการและลดปัญหาที่อาจเกิดขึ้น ทีมพัฒนาควรแสวงหาการมีส่วนร่วมของผู้ใช้ปลายทางและส่งเสริมการป้อนข้อมูลจากผู้ใช้ในกระบวนการพัฒนา การที่ผู้ใช้ไม่เข้ามามีส่วนร่วมอาจนำไปสู่การตีความข้อกำหนดที่ผิดพลาด การไม่คำนึงถึงความต้องการของลูกค้าที่เปลี่ยนแปลงไป และความคาดหวังที่ไม่สมจริงจากฝ่ายลูกค้า นักพัฒนาซอฟต์แวร์ ผู้ใช้ ผู้จัดการโครงการ ลูกค้า และผู้สนับสนุนโครงการจำเป็นต้องสื่อสารกันอย่างสม่ำเสมอและบ่อยครั้ง ข้อมูลที่ได้จากการสนทนาเหล่านี้ช่วยให้ทีมโครงการสามารถวิเคราะห์จุดแข็ง จุดอ่อน โอกาส และภัยคุกคาม (SWOT) และดำเนินการตามข้อมูลนั้นเพื่อใช้ประโยชน์จากโอกาสและลดภัยคุกคาม แม้แต่ข่าวร้ายก็อาจเป็นข่าวดีได้หากสื่อสารตั้งแต่เนิ่นๆ เพราะปัญหาอาจบรรเทาลงได้หากไม่พบปัญหาช้าเกินไป ตัวอย่างเช่น การสนทนาแบบไม่เป็นทางการกับผู้ใช้ สมาชิกในทีม และผู้มีส่วนได้ส่วนเสียอื่นๆ มักจะเปิดเผยปัญหาที่อาจเกิดขึ้นได้เร็วกว่าการประชุมอย่างเป็นทางการ การสื่อสารทั้งหมดต้องมีความซื่อสัตย์และจริงใจทางปัญญา และการวิจารณ์ งานพัฒนาอย่างสม่ำเสมอ บ่อยครั้ง และมีคุณภาพสูง นั้นเป็นสิ่งจำเป็น ตราบใดที่การวิจารณ์นั้นกระทำด้วยท่าทีที่สงบ สุภาพ สร้างสรรค์ไม่กล่าวโทษ และไม่โกรธเคือง การสื่อสารแบบไม่เป็นทางการบ่อยครั้งระหว่างนักพัฒนาและผู้ใช้ปลายทาง และระหว่างผู้จัดการโครงการและลูกค้า เป็นสิ่งจำเป็นเพื่อให้โครงการมีความเกี่ยวข้อง มีประโยชน์ และมีประสิทธิภาพสำหรับผู้ใช้ปลายทาง และอยู่ในขอบเขตของสิ่งที่สามารถทำได้ การสื่อสารระหว่างบุคคลที่มีประสิทธิภาพและการจัดการและการแก้ไขความขัดแย้งเป็นกุญแจสำคัญในการบริหารโครงการซอฟต์แวร์ไม่มีวิธีการหรือกลยุทธ์การปรับปรุงกระบวนการใดที่สามารถเอาชนะปัญหาที่ร้ายแรงในการสื่อสารหรือการจัดการความขัดแย้งระหว่างบุคคลที่ผิดพลาดได้ยิ่งไปกว่านั้น ผลลัพธ์ที่เกี่ยวข้องกับวิธีการและกลยุทธ์การปรับปรุงกระบวนการดังกล่าวจะดีขึ้นด้วยการสื่อสารที่ดีขึ้น การสื่อสารต้องมุ่งเน้นไปที่ว่าทีมเข้าใจแผนงานโครงการ หรือไม่ และทีมกำลังก้าวหน้าไปสู่เป้าหมายนั้นหรือไม่ ผู้ใช้ปลายทาง นักพัฒนาซอฟต์แวร์ และผู้จัดการโครงการต้อง ถาม คำถามพื้นฐาน ง่ายๆ บ่อยๆ เพื่อ ช่วยระบุปัญหาก่อนที่ปัญหาเหล่านั้นจะลุกลามกลายเป็นหายนะแม้ว่าการมีส่วนร่วมของผู้ใช้ปลายทาง การสื่อสารที่มีประสิทธิภาพ และการทำงานเป็นทีมจะไม่เพียงพอ แต่ก็จำเป็นต่อการรับประกันผลลัพธ์ที่ดี และการขาดสิ่งเหล่านี้เกือบจะแน่นอนว่าจะนำไปสู่ผลลัพธ์ที่ไม่ดี^{[ 3 ] [ 4 ] [ 5 ]}
• การจัดการความเสี่ยงคือกระบวนการวัดหรือประเมินความเสี่ยงแล้วจึงพัฒนากลยุทธ์เพื่อจัดการความเสี่ยงนั้น โดยทั่วไป กลยุทธ์ที่ใช้จะรวมถึงการโอนความเสี่ยงไปยังบุคคลอื่น การหลีกเลี่ยงความเสี่ยง การลดผลกระทบเชิงลบของความเสี่ยง และการยอมรับผลที่ตามมาบางส่วนหรือทั้งหมดของความเสี่ยงนั้นๆ การจัดการความเสี่ยงในโครงการพัฒนาซอฟต์แวร์เริ่มต้นด้วยการจัดทำแผนธุรกิจเพื่อเริ่มต้นโครงการ ซึ่งรวมถึงการวิเคราะห์ต้นทุนและผลประโยชน์ ตลอดจนรายการตัวเลือกสำรองในกรณีที่โครงการล้มเหลว ซึ่งเรียกว่าแผน ฉุกเฉิน
  • การจัดการโอกาสเป็นส่วนย่อยของการบริหารความเสี่ยงซึ่งมีความหมายเหมือนกัน เพียงแต่ผลลัพธ์ของความเสี่ยงที่อาจเกิดขึ้นนั้นจะมีผลในเชิงบวกมากกว่าเชิงลบ แม้ว่าในทางทฤษฎีจะจัดการในลักษณะเดียวกัน แต่การใช้คำว่า "โอกาส" แทนคำว่า "ความเสี่ยง" ซึ่งมีความหมายในเชิงลบมากกว่า จะช่วยให้ทีมมุ่งเน้นไปที่ผลลัพธ์เชิงบวกที่อาจเกิดขึ้นจากความเสี่ยง ต่างๆ ในโครงการ เช่น โครงการต่อยอด ผลกำไรก้อนใหญ่ และทรัพยากรเพิ่มเติมโดยไม่เสียค่าใช้จ่าย
• การจัดการความต้องการคือกระบวนการในการระบุรวบรวมจัดทำเอกสาร วิเคราะห์ติดตามจัดลำดับความสำคัญ และตกลงเกี่ยวกับความต้องการ จากนั้นควบคุมการเปลี่ยนแปลงและสื่อสารไปยังผู้มีส่วนได้ส่วนเสียที่เกี่ยวข้องระบบคอมพิวเตอร์ ใหม่หรือที่เปลี่ยนแปลง ^{[ 1 ]}การจัดการความต้องการ ซึ่งรวมถึงการวิเคราะห์ความต้องการเป็นส่วนสำคัญของ กระบวนการ วิศวกรรมซอฟต์แวร์โดยที่นักวิเคราะห์ธุรกิจหรือนักพัฒนาซอฟต์แวร์ระบุความต้องการหรือข้อกำหนดของลูกค้า เมื่อระบุความต้องการเหล่านี้แล้ว พวกเขาก็สามารถออกแบบโซลูชันได้
• การจัดการการเปลี่ยนแปลงคือกระบวนการในการระบุ บันทึก วิเคราะห์ จัดลำดับความสำคัญ และตกลงเกี่ยวกับการเปลี่ยนแปลงขอบเขตงาน (การจัดการโครงการ)จากนั้นควบคุมการเปลี่ยนแปลงและสื่อสารกับผู้มีส่วนได้ส่วนเสียที่เกี่ยวข้องการวิเคราะห์ผลกระทบของการเปลี่ยนแปลงขอบเขตงานใหม่หรือที่แก้ไข ซึ่งรวมถึงการวิเคราะห์ความต้องการในระดับการเปลี่ยนแปลง เป็นส่วนสำคัญของ กระบวนการ วิศวกรรมซอฟต์แวร์โดยที่นักวิเคราะห์ธุรกิจหรือนักพัฒนาซอฟต์แวร์จะระบุความต้องการหรือข้อกำหนดที่เปลี่ยนแปลงไปของลูกค้า เมื่อระบุข้อกำหนดเหล่านี้แล้ว พวกเขาก็จะสามารถออกแบบใหม่หรือปรับเปลี่ยนโซลูชันได้ ในทางทฤษฎี การเปลี่ยนแปลงแต่ละครั้งสามารถส่งผลกระทบต่อระยะเวลาและงบประมาณของโครงการซอฟต์แวร์ ดังนั้นโดยนิยามแล้วจึงต้องมีการวิเคราะห์ความเสี่ยงและผลประโยชน์ก่อนที่จะอนุมัติ
• การจัดการการกำหนดค่าซอฟต์แวร์คือกระบวนการระบุและจัดทำเอกสารขอบเขตของผลิตภัณฑ์ซอฟต์แวร์ที่กำลังพัฒนา รวมถึงผลิตภัณฑ์ย่อยและการเปลี่ยนแปลงทั้งหมด และการสื่อสารสิ่งเหล่านี้ไปยังผู้มีส่วนได้ส่วนเสียที่เกี่ยวข้อง โดยทั่วไป กระบวนการที่ใช้จะรวมถึงการควบคุมเวอร์ชัน ข้อกำหนดการตั้งชื่อ ( การเขียนโปรแกรม)และข้อตกลงการเก็บรักษาซอฟต์แวร์
• การจัดการการเผยแพร่ซอฟต์แวร์คือกระบวนการในการระบุ บันทึก จัดลำดับความสำคัญ และตกลงเกี่ยวกับการเผยแพร่ซอฟต์แวร์ จากนั้นควบคุมตารางการเผยแพร่และสื่อสารกับผู้มีส่วนได้ส่วนเสียที่เกี่ยวข้อง โครงการซอฟต์แวร์ส่วนใหญ่สามารถเข้าถึงสภาพแวดล้อมซอฟต์แวร์ได้สามสภาพแวดล้อม ได้แก่ สภาพแวดล้อมการพัฒนา การทดสอบ และการใช้งานจริง ในโครงการขนาดใหญ่มาก ซึ่งทีมงานที่กระจายอยู่ต้องบูรณาการงานของตนก่อนที่จะเผยแพร่ให้กับผู้ใช้ มักจะมีสภาพแวดล้อมสำหรับการทดสอบมากกว่านั้น เรียกว่า การทดสอบหน่วยการทดสอบระบบหรือการทดสอบการบูรณาการก่อนที่จะเผยแพร่ไปยังการทดสอบการยอมรับของผู้ใช้ (UAT)
  • การ จัดการข้อมูลเป็นส่วนย่อยของการจัดการการเผยแพร่ซอฟต์แวร์ที่กำลังได้รับความสนใจมากขึ้นเนื่องจากเห็นได้ชัดว่าผู้ใช้สามารถทดสอบได้เฉพาะกับข้อมูลที่พวกเขารู้จักเท่านั้น และข้อมูล "จริง" จะอยู่ในสภาพแวดล้อมซอฟต์แวร์ที่เรียกว่า "สภาพแวดล้อมการผลิต" เท่านั้น ดังนั้น เพื่อทดสอบงานของตน โปรแกรมเมอร์จึงมักต้องสร้าง "ข้อมูลจำลอง" หรือ "ข้อมูลต้นแบบ" ขึ้นมาด้วย ในอดีต เวอร์ชันเก่าของระบบการผลิตมักถูกนำมาใช้เพื่อจุดประสงค์นี้ แต่เนื่องจากบริษัทต่างๆ พึ่งพาผู้ร่วมงานภายนอกในการพัฒนาซอฟต์แวร์มากขึ้นเรื่อยๆ ข้อมูลของบริษัทจึงอาจไม่ได้ถูกเผยแพร่ให้กับทีมพัฒนา ในสภาพแวดล้อมที่ซับซ้อน อาจมีการสร้างชุดข้อมูลขึ้นมาแล้วย้ายไปยังสภาพแวดล้อมการทดสอบตามกำหนดการเผยแพร่การทดสอบ เช่นเดียวกับกำหนดการเผยแพร่ซอฟต์แวร์โดยรวม
• การบำรุงรักษาและการอัปเดตเป็นกระบวนการที่เกี่ยวข้องกับข้อกำหนดและความต้องการของลูกค้าอยู่เสมอ ลูกค้าอาจพบข้อผิดพลาด ขอคุณสมบัติใหม่ และขอฟังก์ชันการทำงานที่แตกต่างออกไป รวมถึงการอัปเดตเพิ่มเติม ดังนั้นจึงต้องตรวจสอบและตอบสนองความต้องการและความพึงพอใจของลูกค้าในทุกคำขอเหล่านั้น

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

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

ในด้านการคำนวณ คำว่า "ปัญหา" หมายถึงหน่วยงานที่ต้องดำเนินการเพื่อปรับปรุงระบบ^{[ 6 ]} ปัญหาอาจเป็นบั๊กคุณสมบัติที่ร้องขอ งาน เอกสารที่ขาดหายไปและอื่นๆ

ตัวอย่างเช่นOpenOffice.orgเคยเรียกBugzilla เวอร์ชันที่แก้ไขแล้วว่า IssueZilla แต่ในเดือนกันยายน พ.ศ. 2553 พวกเขาเรียกระบบนี้ว่า Issue Tracker ^{[ 7 ]}

ปัญหาต่างๆ มักถูกจัดประเภทตามระดับความรุนแรงบริษัทต่างๆ อาจมีนิยามของระดับความรุนแรงที่แตกต่างกัน แต่นิยามที่พบได้บ่อยที่สุดมีดังนี้:

สูง

บั๊กหรือปัญหาดังกล่าวส่งผลกระทบต่อส่วนสำคัญของระบบ และต้องได้รับการแก้ไขเพื่อให้ระบบกลับมาทำงานได้ตามปกติ^{[ 8 ]}

ปานกลาง

บั๊กหรือปัญหาดังกล่าวส่งผลกระทบต่อส่วนเล็ก ๆ ของระบบ แต่มีผลกระทบต่อการทำงานของระบบ ระดับความรุนแรงนี้จะถูกกำหนดเมื่อความต้องการที่ไม่ใช่ส่วนกลางของระบบได้รับผลกระทบ^{[ 9 ]}

ต่ำ / คงที่

บั๊กหรือปัญหาดังกล่าวส่งผลกระทบต่อส่วนเล็ก ๆ ของระบบ และมีผลกระทบต่อการทำงานของระบบน้อยมาก ระดับความรุนแรงนี้จะถูกกำหนดเมื่อความต้องการที่ไม่ใช่ส่วนกลางของระบบ (และมีความสำคัญน้อยกว่า) ได้รับผลกระทบ^{[ 10 ]}

เล็กน้อย (ด้านความสวยงาม)

ระบบทำงานได้อย่างถูกต้อง แต่ลักษณะที่ปรากฏไม่ตรงกับที่คาดหวัง ตัวอย่างเช่น สีผิด ระยะห่างระหว่างเนื้อหามากเกินไปหรือน้อยเกินไป ขนาดตัวอักษรไม่ถูกต้อง พิมพ์ผิด ฯลฯ นี่คือปัญหาที่มีความรุนแรงน้อยที่สุด^{[ 11 ]}

ในการพัฒนาซอฟต์แวร์บางรูปแบบ ปัญหาต่างๆ จะถูกตรวจสอบโดยนักวิเคราะห์การประกันคุณภาพระบบจะได้รับการตรวจสอบความถูกต้อง จากนั้นจึงมอบหมายให้สมาชิกในทีมพัฒนาแก้ไขปัญหาที่พบ นอกจากนี้ ปัญหาต่างๆ ยังสามารถระบุได้โดยผู้ใช้ระบบในระหว่างขั้นตอน การทดสอบการยอมรับของผู้ใช้ (UAT)

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

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

• สื่อที่เกี่ยวข้องกับการจัดการโครงการซอฟต์แวร์ในวิกิมีเดียคอมมอนส์

• Robert Frese (16 ธันวาคม 2003). "ความสำเร็จและความล้มเหลวของโครงการ: ความสำเร็จคืออะไร ความล้มเหลวคืออะไร และคุณจะเพิ่มโอกาสแห่งความสำเร็จได้อย่างไร?"มหาวิทยาลัยมิสซูรี-เซนต์หลุยส์สืบค้นเมื่อ 13 พฤษภาคม2015