CMM กับ การพัฒนาซอฟต์แวร์(ต่อ)

1 1 2 3 4 5 มหาวิทยาลัยอีสเทิร์นเอเซีย หลักสูตร วิทยาศาสตร์ มหาบัณฑิต สาขาวิชา เทคโนโลยีสารสนเทศ คณะ บัณฑิตวิทยาลัย ภาคการศึกษา 2 ปี การศึกษา 2549 แผนการสอนรายวิชา (Course Syllabus) รหัสวิชา 221-2113 จานวนหน่วยกิต 3(3-0-6) ชื่อวิชา Software Project Management การจัดการโครงงานซอฟต์แวร์ ชื่อผู้สอน อาจารย์ประจา ดร.ราชันย์ เหล็กกล้ า อาจารย์พิเศษ อ.พิชยั ตรรกบุตร เงื่อนไขรายวิชา หมวดวิชาบังคับเฉพาะ 6. จานวนชัว่ โมงที่สอน/สัปดาห์ : 3 ชัว่ โมง/สัปดาห์ (วันเสาร์ 13.00-16.00 น.) 7. เนื ้อหารายวิชา Course Description อธิบายขันตอนการบริ ้ หารโครงการ เริ่มตังแต่ ้ การกาหนดโครงงานวางแผน การเป็ นผู้นาโครงงาน การตรวจสอบดูแล เริ่มตังแต่ ้ การกาหนดตารางเวลา งบประมาณเพื่อให้ ได้ ประสิทธิภาพ เทคนิคการเจรจาต่อรองการเขียนสัญญาข้ อตกลง เครื่ องมือที่ใช้ ในการจัดตารางเวลา การประมาณค่าใช้ จา่ ย เวลา แผนผังการทางานโดยใช้ PERT/CPM การบริหารทีมงาน หลักการของผู้บริหารโครงงาน เครื่ องมือในการตรวจสอบดูแล แนวทางการจัดซื ้อภาครัฐ กรณีศกึ ษาโครงการที่ล้มเหลวและโครงการที่ประสบผลสาเร็จ 8. ประมวลการเรี ยนรายวิชา 8.1 วัตถุประสงค์เชิงพฤติกรรม  เพื่อให้ นกั ศึกษามีความรู้ ความเข้ าใจในหลักการ และนาประสบการทางวิชาการหลักสูตรจากหลากหลายสาขา(Inter-disciplinary) และหลักสูตร MSIT เช่นวิศวกรรมซอฟต์แวร์ การวิเคราะห์และออกแบบระบบงาน รวมทังประสบการณ์ ้ การทางานของนักศึกษา ที่ผา่ นในหน่วยงานภาครัฐและเอกชน ซึง่ นักศึกษาสามารถนามา ประยุกต์ใช้ และพัฒนาการบริหารจัดการโครงการพัฒนาซอฟต์แวร์ ได้ อย่างมีระบบ สร้ างทักษะในการติดต่อสื่อสาร มีคณ ุ ธรรม จริยธรรม และความรับผิดชอบต่อสังคม และมี คุณสมบัตทิ างวิชาชีพ ที่จะต้ องรับใช้ สงั คมภาครัฐและเอกชนต่อไป Eau2547.doc 2  เพื่อให้ นกั ศึกษา มีการจัดการพฤติกรรมการเรี ยนรู้ของนักศึกษา โดยการใช้ ความคิดริเริ่มสร้ างสรรค์ จัดทาโครงการศึกษาของส่วนบุคคล (IS=Individual Study) และโครงการศึกษาแบบรวมกลุ่ม(GS=Group Study) โดยอาศัยระเบียบวิธีการนาเสนอผลงาน และจัดทารายงานแบบ วิทยานิพนธ์ หรื อสาระนิพนธ์ เพื่อนามาประยุกต์อภิปรายในชันเรี ้ ยน และจัดทารายงาน IS และGS ส่งสาหรับประกอบการประเมินผล รวมเป็ นคะแนนกับการสอบปลายภาค 8.2 วัตถุประสงค์ ของ EAU  เพื่อผลิตมหาบัณฑิตที่มีคณ ุ ภาพ มีความรู้และทักษะในการบริ หารจัดการกับระบบเทคโนโลยีสารสนเทศ  เพื่อผลิตมหาบัณฑิตที่มีคณ ุ ภาพ มีความรู้และทักษะในการวิเคราะห์ ออกแบบ และสร้ างระบบเทคโนโลยีสารสนเทศ  เพื่อให้ บณ ั ฑิตที่ศกึ ษาในสาขาวิชาการต่าง ๆ ได้ มีโอกาส และแสวงหา การศึกษาในระดับปริญญาโท ด้ านเทคโนโลยีสารสนเทศ 8.3 เนื ้อหารายวิชาต่อสัปดาห์ (Course Outline) สัปดาห์ที่/วัน หัวข้อ หมายเหตุ เดือน ปี 28 ตุลาคม 49 1. ความหมายการจัดการโครงงาน/โครงการ 2. ความล้มเหลวและโครงการที่ประสบผลสาเร็ จ 3. แนวคิด นิยาม วิวฒั นาการ ปั ญหา เกี่ยวกับ Software ในยุคต่างๆ โครงสร้ าง ของวิศวกรรมซอฟต์ แวร์ พื้นฐานการพัฒนาระบบ ทักษะการวิเคราะห์ระบบ ทักษะการออกแบบระบบ การบริ หารโครงการซอฟต์แวร์ VS. CMMI แนวทางบริ หารโครงการเพื่อเข้าสู่ CMM Level 2 Eau2547.doc 3 สัปดาห์ที่/วัน หัวข้อ เดือน ปี 4 พย. 49  การพัฒนาซอฟต์แวร์ VS. การบริ หารการพัฒนาซอฟต์แวร์  ระเบียบวิธีการจัดทาโครงงาน Proposalเพื่อการจัดทาวิทยานิพนธ์ สาระนิพนธ์ VS. Systems Analysis and Design  วิธีจดั ทาสาระนิพนธ์ ในรายละเอียด การจัดทาข้อกาหนดความต้องการซอฟต์แวร์ (Terms of Reference: TOR) 11 พย. 49 สรุ ปขอบเขตการบริ หารโครงการ Scope=Time + resources(CSF)  หลักการ และขั้นตอนการบริ หารโครงการ เริ่ มตั้งแต่การกาหนดโครงงานวางแผน 18 พย. 49 สรุ ปขอบเขตการบริ หารโครงการ Scope=Time + resources(CSF)  การเป็ นผูน้ าโครงงาน การตรวจสอบดูแล เงื่อนไขการกาหนด ตารางเวลางบประมาณเพื่อให้ได้ประสิ ทธิ ภาพ 25 พย. 49 สรุ ปขอบเขตการบริ หารโครงการ Scope=Time + resources(CSF)  เทคนิคการเจรจาต่อรอง การเขียนสัญญา ข้อตกลง  เครื่ องมือที่ใช้ในการจัดตารางเวลา การประมาณค่าใช้จ่าย เวลา แผนผังการทางานโดยใช้ PERT/CPM 2 ธค. 49 สรุ ปขอบเขตการบริ หารโครงการ Scope=Time + Eau2547.doc หมายเหตุ นักศึกษานาเสนอร่ าง Proposalเพื่อพัฒนาสู่ สาระนิ พนธ์ QUIZ QUIZ Take Home Take Home 4 resources(CSF)  วิธีการให้ ได้ ประสิทธิภาพ เทคนิคการเจรจาต่อรองการเขียนสัญญาข้ อต กลง สัปดาห์ที่/วัน หัวข้อ หมายเหตุ เดือน ปี 9 ธค. 49 สรุ ปขอบเขตการบริ หารโครงการ Scope=Time + resources(CSF) Take Home  การบริ การทีมงาน หลักการของผูบ้ ริ หารโครงงาน เครื่ องมือในการตรวจสอบดูแล 16 ธค. 49 23 ธค. 49 6 มค . 50 Take  แนวทางการจัดซื้อภาครัฐ  กรณีศกึ ษาโครงการที่ล้มเหลวและโครงการที่ประสบผลสาเร็จ Home  มอบหมายโครงการศึกษาของส่วนบุคคลและกลุม่ (IS=Individual Study , GP=Group Study) Presentation Presentation 8.3 วิธีการจัดการเรี ยนการสอน  แบบกรณีศกึ ษา  แบบสาธิต  แบบโครงการ  แบบบรรยาย  แบบสัมมนา  แบบ Brain Storming Group  แบบรายงานเชิงปฏิบตั กิ าร 8.4 สื่อการสอน  Video Projector  กระดาน Eau2547.doc 5 8.5 การวัดผลการเรี ยน  การนาเสนอและอภิปรายในชันเรี ้ ยน 20%  การจัดทารายงานโครงการ 60% o จัดทา Individual Study (IS) o จัดทา Group Study (GS)  การสอบไล่ 20% 9. รายชื่อหนังสืออ่านประกอบ  หนังสือบังคับ o David Williams and Dr. Charles Duncan, Project Management: Skills for Success o สุชาย ธนวเสถียร และคณะ Software Project Development o รศ. ดร. สมชาย ภคภาสน์วิวฒ ั น์ , กลยุทธ์การเจรจาการต่อรอง พิมพ์ครัง้ ที่ 2 กรกฎาคม 2545 o พิชยั ตรรกบุตร เอกสารโรเนียว และ Web Site, takkabutr.com o การวิเคราะห์โครงการและแผนงาน มหาวิทยาลัยสุโขทัยธรรมาธิราช สาขาวิชาเศรษฐศาสตร์ o นอ. อโณทัย นอบไทย รน. หงษ์ลดั ดา พงศ์สวุ รรณ แปล Steve McConnell, Software project survival guide บริษัทซอฟต์แวร์ ปาร์ คจากัด และ softwarepark.co.th/survivalguide o Kanchit.com o Google.com search key word software project management ppt pdf edu doc Eau2547.doc 6 Eau2547.doc 7 สองทศวรรษแล้ ว เมื่อแรกเริ่มที่ผมใช้ เครื่อง IBM 1130 อันเป็ นคอมพิวเตอร์ ขนาดเล็กมากที่สถาบันเทคโนโลยีแห่ งเอเซียเช่ ามาจากไอบีเอ็มนัน้ ซอฟต์ แวร์ ทุกอย่ างทางไอบีเอ็มให้ มาโดยไม่ คิดเงินเลย นับตัง้ แต่ ระบบควบคุม (Monitor system) คอมไพเลอร์ ซับรู ทีนสาหรั บงานวิทยาศาสตร์ และสถิติ ตลอดจนโปรแกรมประยุกต์ ต่าง ๆ สุดแท้ แต่ จะต้ องการ แต่ พอใช้ ไปได้ ไม่ ก่ ีปี ไอบีเอ็มก็แจ้ งว่ าต่ อไปนีใ้ ห้ เปล่ าไม่ ได้ แล้ ว จะต้ องคิดเงินค่ าเช่ าซอฟต์ แวร์ ด้วย ผมเองก็แปลกใจเพราะคิดเหมือน ๆ กับ ที่หลายคนคิดในขณะนีว้ ่ าซอฟต์ แวร์ น่าจะเป็ นของได้ เปล่ า แต่ น่ ันเป็ นช่ วงที่ไอบีเอ็มกาลังมีปัญหากับทางรั ฐบาลในเรื่ องการผูกขาดธุรกิจ หากไอบีเอ็มไม่ คิดเงินก็จะกลายเป็ นว่ าไอบีเอ็มตัดหนทางการค้ าของบริษัทซอฟต์ แวร์ อ่ ื น ๆ ซึ่งเริ่มจะเกิดขึน้ แล้ ว ผมนั่งคิดต่ อไปว่ านักศึกษาของเอไอทีท่ พ ี ัฒนาโปรแกรมเยี่ยม ๆ ทางด้ านวิศวกรรมนัน้ มีอยู่มาก แต่ เมื่อทาโปรแกรมจนสาเร็จได้ ผล และ นักศึกษาเองก็จบไปแล้ ว โปรแกรมเหล่ านีก้ ็จะกระจัดกระจายหายไป ไม่ เกิดประโยชน์ อันใด ผมจึงนาเรื่องเสนอต่ อสถาบันให้ บังคับนักศึกษาทุกคนจะต้ องส่ งโปรแกรมที่พัฒนาแล้ วมา เก็บไว้ ท่ ศี ูนย์ คอมพิวเตอร์ โดยผมกะว่ าในอนาคตศูนย์ คอมพิวเตอร์ ของผมจะเป็ นศูนย์ กลางซอฟต์ แวร์ ด้านวิศวกรร มที่ใหญ่ ท่ สี ุดในภูมิภาคเลยทีเดียว ความคิดของผมไม่ เป็ นผล แม้ ทางสถาบันจะยอมทาตามผมโดยไม่ ทราบความสาคัญของโปรแกรมเหล่ านีม้ ากนัก แต่ ผมก็ไม่ สามารถนาโปรแกรมเหล่ านัน้ มาตรวจสอบ แก้ ไข จัดหมวดหมู่ และทาดัชนีเก็บไว้ ใช้ งานได้ เพราะไม่ มีกาลังคนที่ร้ ู ทัง้ ด้ านคอมพิวเตอร์ และงานวิศวกรรม จะใช้ นักศึกษาก็ไม่ ได้ เพราะเขาก็จะต้ องรีบเร่ งทาวิทยานิพนธ์ ของตนเองให้ จบ ดังนัน้ สุดท้ ายผมเชื่อว่ าป่ านนีโ้ ปรแกรมที่ผมได้ รวบรวมไว้ หลายพันหลายหมื่นโปรแกรมก็ คงจะกระจัดกระจายสูญหายไปหมดแล้ ว สาเหตุอีกข้ อหนึ่งก็คือผมยังไม่ ได้ เรี ยนรู้ หลักการทาโปรแกรมและซอฟต์ แวร์ ให้ เป็ นอุตสา หกรรม ยังไม่ ทราบความสาคัญของการควบคุมคุณภาพซอฟต์ แวร์ และที่สาคัญยังไม่ ได้ ศึกษาเรื่ องของมาตรฐานต่ าง ๆ ทางด้ านซอฟต์ แวร์ Eau2547.doc 8 ในช่ วงนัน้ ผมคิดแต่ เพียงว่ าแต่ ละปี นักศึกษาแต่ ละคนต้ องเขียนโปรแกรมสาหรับใช้ ในงาน วิทยานิพนธ์ ระดับก้ าวหน้ าออกมาคนละหลาย ๆ โปรแกรม ผมเชื่อจริง ๆ ว่ า หากได้ ทาจริงจัง โปรแกรมเหล่ านีก้ ็จะเป็ นรายได้ ให้ กับทางสถาบันได้ แต่ ไม่ เคยคิดหรอกครับว่ าจะมีคนสร้ างความร่ ารวยมหาศาลจากโปรแกรมได้ เหมือนบริษั ทซอฟต์ แวร์ เวลานี ้ ต่ อมา ทางกระทรวงวิทยาศาสตร์ ฯ ก็เริ่มคิดฝั นเหมือนผมเหมือนกันว่ า ซอฟต์ แวร์ น่าจะเป็ นอุตสาหกรรมสาหรับทารายได้ ให้ แก่ ประเทศได้ ไม่ ได้ คิดเฉย ๆ กระทรวงฯ ยังถึงกับตัง้ กรรมการอุตสาหกรรมซอฟต์ แวร์ ขนึ ้ มาด้ วย แต่ คณะกรรมการก็นัดประชุมได้ ไม่ ก่ ีครัง้ ก็มีอันต้ องเลิกลา สลายกันไปหมด จนกระทั่งขณะนี ้ ทางเนคเทคสามารถผลักดันโครงการซอฟต์ แวร์ พาร์ คจนได้ รับงบประมาณ และดาเนินการ ก้ าวหน้ าไปจนถึงขัน้ ซือ้ อาคารมาเป็ นสานักงานโครงการได้ แล้ ว แต่ งานด้ านอุตสาหกรรมซอฟต์ แวร์ ของเราก็ยังคงล้ มลุกคลุกคลาน ไม่ ได้ ตงั ้ ไข่ สักที เรื่องที่น่าเจ็บปวดก็คือ โครงการนีไ้ ด้ รับความเห็นชอบเมื่อประเทศชาติกาลังหมดตัว ดังนัน้ ลาพังแต่ จะทาให้ เป็ นโครงการที่จะสร้ างความเชื่อมั่นให้ แก่ บริษัทซอฟต์ แวร์ ประเท ศอื่นก็ยังไม่ สามารถทาได้ ประเทศอื่นหลายประเทศได้ ผลักดันโครงการอุตสาหกรรมซอฟต์ แวร์ นาหน้ าเราไปไกลแล้ ว ยกตัวอย่ างเช่ นอินเดียเริ่มก่ อนหน้ าเรานานถึงยี่สิบปี ไต้ หวันที่นาหน้ าเราอยู่แล้ วทางด้ านฮาร์ ดแวร์ ก็เริ่มมีซอฟต์ แวร์ พาร์ กสาหรั บหนีเราไปอีกไกลสุดกู่ มาเลเซียที่ว่าย่ อบแย่ บก็ยังผลักดันโครงการ Multimedia Super Corridor ต่ อไปในอาณาบริเวณที่มีเนือ้ ที่กว้ างกว่ าประเทศสิงคโปร์ แต่ ของไทยเรานัน้ ลาพังจะหาอาคารสาหรับเป็ นที่ทาการให้ ได้ สักหลังยังไม่ ได้ เวลาไปพูดกับใครเขาบอกว่ าได้ มาแค่ ส่ ีชัน้ ก็บุญแล้ ว การพัฒนาซอฟต์ แวร์ ให้ เป็ นอุตสาหกรรมสาคัญของไทยนัน้ มีเรื่องที่จะต้ องดาเนินการอีก มาก อย่ าได้ นึกเป็ นอันขาดเชียวว่ า เรียน Visual BASIC จากโครงการของกระทรวงแรงงานฯ แล้ วจะทาให้ สร้ างอุตสาหกรรมซอฟต์ แวร์ ได้ หรือจะทาให้ ร่ ารวยเหมือนบิลล์ เกตส์ เวลานีก้ ารพัฒนาซอฟต์ แวร์ ของไทยนัน้ ยังล้ าหลังประเทศอื่น ๆ อีกมาก ความรู้ ในด้ านการพัฒนาซอฟต์ แวร์ ของเรายังด้ อยกว่ าของประเทศอื่นมาก อาจจะเป็ นเพราะเราไม่ ได้ พัฒนาซอฟต์ แวร์ อย่ างเป็ นล่าเป็ นสันมาก่ อน อาจจะเป็ นเพราะการเรียนการสอนด้ านซอฟต์ แวร์ ของเรายังไม่ ก้าวหน้ า หรื อ อาจจะเป็ นเพราะไม่ มีนักซอฟต์ แวร์ ท่ มี ีประสบการณ์ ต่อเนื่องเป็ นเวลานาน ๆ ก็ได้ ทงั ้ สิน้ การที่จะส่ งเสริมการพัฒนาซอฟต์ แวร์ ในเมืองไทยให้ ร่ ุงเรืองจนเป็ นอุตสาหกรรมได้ Eau2547.doc 9 จึงจาเป็ นที่จะต้ องพัฒนาความรู้ ความสามารถในด้ านวิศวกรรมซอฟต์ แวร์ ให้ ก้าวหน้ าทัดเ ทียมกับประเทศอื่นได้ ก่อน ปั จจุบันนีค้ วามก้ าวหน้ าทางด้ านซอฟต์ แวร์ ของต่ างประเทศได้ ลา้ หน้ าประเทศไทยไปมาก การจะพัฒนาความรู้ ขนึ ้ ได้ จึงจาเป็ นจะต้ องค่ อย ๆ เก็บเนือ้ หาที่น่าสนใจมาเล่ าสู่กันฟั งไปตามลาดับ หากใครสนใจต้ องการศึกษาค้ นคว้ าต่ อก็จะได้ มีแหล่ งอ้ างอิงที่เป็ นหลักเป็ นฐาน เรื่องแรกที่จะนามาเสนอในที่นีก้ ็คือเรื่อง Capability Maturity Model ทางด้ านซอฟต์ แวร์ แต่ ก่อนจะไปถึงเรื่ องนีค้ งจะต้ องเริ่มที่เรื่องของ SEI สถาบันวิศวกรรมซอฟต์แวร์ การเป็ นวิศวกรซอฟต์ แวร์ ยังไม่ ได้ รับการรั บรองให้ เป็ นวิชาชีพก็จริงอยู่ แต่ งานทางด้ านนีม้ ีความสาคัญอย่ างยิ่ง ทุกวันนีซ้ อฟต์ แวร์ มีขนาดใหญ่ ขนึ ้ และซับซ้ อนมากขึน้ จนสุดวิสัยที่จะมีใครพัฒนาระบบเห ล่ านีไ้ ด้ คนเดียว การพัฒนาซอฟต์ แวร์ ร่วมกันหลายคนจึงจาเป็ นจะต้ องมีกฎเกณฑ์ และแนวทางในการทาง านอย่ างรัดกุม ก็การพัฒนาซอฟต์ แวร์ หรื อโปรแกรมในอดีตนัน้ ถือกันว่ าเป็ นศิลปะแบบหนึ่ง ดังที่ โดนัลด์ คนุธ ศาสตราจารย์ ของมหาวิทยาลัยสแตนฟอร์ ดยังเขียนตาราการเขียนโปรแกรมที่เลื่องชื่อออ กมาชุดหนึ่งในชื่อว่ า The Art of Programming เมื่อเป็ นศิลปะจึงยากที่จะกาหนดกฎเกณฑ์ ว่าใครจะทาอะไรก่ อนอะไรหลัง จะทาอย่ างไร หรือจะควบคุมตรวจสอบกันอย่ างไร ในเมื่อซอฟต์ แวร์ หรื อโปรแกรมเป็ นงานสร้ างสรรค์ ทางปั ญญาที่ซับซ้ อน การที่จะสื่อความกันระหว่ างการพัฒนาโปรแกรมจึงเป็ นเรื่องยาก งานซอฟต์ แวร์ ขนาดใหญ่ จึงมักจะลงเอยด้ วยความล้ มเหลวยิ่งกว่ าความสาเร็จ ด้ วยเหตุนีเ้ อง เมื่อยี่สิบปี มานีบ้ รรดาเกจิอาจารย์ ทางด้ านซอฟต์ แวร์ ทงั ้ หลายจึงเริ่มปรึกษาหาแนวทางที่ จะทาให้ การพัฒนาซอฟต์ แวร์ ประสบความสาเร็จมากขึน้ และหลังจากนัน้ ไม่ นานก็เริ่มมีผ้ ูคิดกระบวนการตลอดจนตัวแบบต่ าง ๆ สาหรับการพัฒนาซอฟต์ แวร์ ออกมาเผยแพร่ มากขึน้ ในกระบวนความคิดเหล่ านี ้ ความคิดที่ว่าการพัฒนาซอฟต์ แวร์ ควรจะอิงอาศัยแบบอย่ างงานด้ านวิศวกรรมที่มีระเบีย บวิธีและขัน้ ตอนที่กาหนดไว้ ชัดเจนเป็ นอย่ างดี ดูจะได้ รับความสนใจมากที่สุด และทาให้ เกิดแนวคิดเรื่อง วิศวกรรมซอฟต์ แวร์ ขึน้ Eau2547.doc 10 วิศวกรรมซอฟต์ แวร์ ม่ ุงที่จะใช้ หลักการด้ านวิศวกรรมในการตอบคาถาม หรือ หาทางดาเนินการในด้ านต่ อไปนี ้          เรากาลังแก้ ปัญหาอะไร ปั ญหานัน้ เกี่ยวกับอะไรบ้ าง ลักษณะของสิ่งที่จะนามาใช้ แก้ ปัญหาได้ เป็ นอย่ างไร แนวทางแก้ ปัญหาเป็ นเช่ นใด เราจะสร้ างคาตอบ หรือ สิ่งที่จะใช้ แก้ ปัญหาได้ อย่ างไร เราจะรู้ ได้ อย่ างไรว่ าคาตอบนัน้ แก้ ปัญหาได้ เราจะขจัดข้ อบกพร่ องหรื อผิดพลาดในสิ่งที่ใช้ แก้ ปัญหาได้ อย่ างไร เราจะควบคุมกระบวนการสร้ างคาตอบหรือสิ่งที่จะใช้ แก้ ปัญหาได้ อย่ างไร เราจะรู้ ได้ อย่ างไรว่ าสิ่งที่เราใช้ แก้ ปัญหานัน้ แก้ ปัญหาได้ จริง ในเมื่อการพัฒนาซอฟต์ แวร์ นัน้ อาจกล่ าวได้ ว่าเกี่ยวข้ องกับการแก้ ปัญหาอย่ างใดอย่ างหนึ่ ง กระบวนการพัฒนาซอฟต์ แวร์ จึงนาขัน้ ตอนการแก้ ปัญหามาใช้ เป็ นแบบอย่ างในการพัฒน าซอฟต์ แวร์ ด้วย นั่นคือ [1]    การกาหนดปั ญหา เป็ นการกาหนดว่ าปั ญหาที่ต้องการจัดทาซอฟต์ แวร์ ขนึ ้ คืออะไร มีลักษณะอย่ างไร อะไรคือคาตอบหรือผลที่ต้องการ ซอฟต์ แวร์ นัน้ จะต้ องดาเนินการกับข้ อมูลอะไรบ้ าง ซอฟต์ แวร์ จะต้ องทาหน้ าที่อะไร จะต้ องมีความสามารถมากขนาดใด จะต้ องมีพฤติกรรมอย่ างไร จะต้ องจัดทาอินเทอร์ เฟสแบบใด มีเงื่อนไขข้ อกาหนดในการออกแบบซอฟต์ แวร์ อย่ างไรบ้ าง มีวิธีการตรวจสอบความถูกต้ องอย่ างไรบ้ าง การพัฒนาซอฟต์ แวร์ เป็ นการเน้ นว่ าจะสร้ างซอฟต์ แวร์ ได้ อย่ างไรและจะให้ ซอฟต์ แวร์ ทางานอย่ างไร ในขัน้ ตอนนีผ้ ้ ูพัฒนาซอฟต์ แวร์ จะต้ องพยายามกาหนดว่ าจะสร้ างข้ อมูลอย่ างไร จะกาหนดโครงสร้ างของซอฟต์ แวร์ อย่ างไร จะถ่ ายทอดโครงสร้ างลงเป็ นตัวโปรแกรมได้ อย่ างไร และจะทดสอบโปรแกรมอย่ างไร การบารุงรักษาซอฟต์ แวร์ เป็ นการเน้ นว่ าจะเปลี่ยนแปลงซอฟต์ แวร์ ได้ อย่ างไร เช่ นจะขยายซอฟต์ แวร์ ให้ มีความสามารถมากขึน้ Eau2547.doc 11 จะแก้ ความบกพร่ องผิดพลาดในโปรแกรม หรือ จะปรับเปลี่ยนอย่ างไรในเมื่อสิ่งแวดล้ อมของโปรแกรมเปลี่ยนไป สถาบัน IEEE ได้ ให้ คานิยามของวิศวกรรมซอฟต์ แวร์ ในปี 1993 ว่ า Software engineering: (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) the study of approaches as in (1). เมื่อปี 1984 กระทรวงกลาโหมสหรัฐฯ เล็งเห็นการพัฒนาซอฟต์ แวร์ มีความสาคัญอย่ างยิ่งต่ อการปฏิบัตกิ ารด้ านต่ าง ๆ ของกระทรวง หากการพัฒนาซอฟต์ แวร์ ยังมีปัญหาแล้ วอาจส่ งผลให้ เกิดข้ อบกพร่ องร้ ายแรงในซอฟต์ แ วร์ ต่าง ๆ อันอาจจะเป็ นผลร้ ายต่ อการดาเนินงานต่ าง ๆได้ ดังนัน้ กระทรวงกลาโหมฯ จึงตัง้ โครงการจัดตัง้ สถาบันวิศวกรรมซอฟต์ แวร์ ขนึ ้ และขอให้ มหาวิทยาลัยต่ าง ๆ ในสหรัฐฯ ที่ต้องการได้ รับเงินทุนไปจัดตัง้ สถาบันนีส้ ่ งข้ อเสนอมาให้ พจิ ารณา ผลปรากฏว่ ามหาวิทยาลัยคาร์ เนกี เมลลอน ได้ รับเลือกให้ เป็ นผู้ดาเนินการสถาบันนี ้ สถาบันวิศวกรรมซอฟต์ แวร์ (Software Engineeging Institute) จึงเกิดขึน้ โดยมีเจ้ าหน้ าที่และผู้เชี่ยวชาญจากมหาวิทยาลัย จากภาครั ฐ และ ภาคอุตสาหกรรม เข้ ามาทางานร่ วมกัน โดยมีภารกิจสาคัญที่จะเป็ นผู้นาในการผลักดันระดับความสามารถทางด้ านวิศวกรรมซอ ฟต์ แวร์ ให้ ก้าวหน้ ามากขึน้ และ เพื่อปรับปรุงระบบต่ าง ๆ ที่ต้องอาศัยซอฟต์ แวร์ เป็ นพืน้ ฐานการทางาน [2]งานหลักของ SEI ก็คือการเปลี่ยนการพัฒนาซอฟต์ แวร์ จากรู ปแบบการทางานที่ใช้ คนจานวนมาก และ ทางานอย่ างไม่ มีหลักเกณฑ์ ให้ กลายเป็ นงานที่มีระบบและกฎเกณฑ์ อีกทัง้ ยังสามารถควบคุมและจัดการให้ เป็ นไปตามที่เหมาะที่ควรได้ ภารกิจของ SEI มีอยู่สองด้ านคือ   เพิ่มขีดความสามารถในการจัดการ งานส่ วนนีเ้ น้ นในด้ านการทาให้ องค์ การสามารถพยากรณ์ และ ควบคุม คุณภาพ กาหนดเวลา ต้ นทุน และ ผลผลิต ในการจัดหา สร้ าง หรือปรับปรุงระบบซอฟต์ แวร์ พัฒนาแนวทางด้ านเทคนิควิศวกรรม งานส่ วนนีเ้ น้ นในด้ านความสามารถของวิศวกรในการวิเคราะห์ พยากรณ์ และ ควบคุม สมบัตบิ างประการของระบบซอฟต์ แวร์ Eau2547.doc 12 งานส่ วนนีเ้ กี่ยวกับการกาหนดทางเลือกสาคัญ ๆ ระหว่ างการจัดหา สร้ าง หรื อ ปรับปรุงระบบซอฟต์ แวร์ กระบวนการซอฟต์แวร์ คาว่ า กระบวนการซอฟต์ แวร์ (software process) เป็ นคาที่ใช้ กันมากสาหรับระบุงานต่ าง ๆ ที่เกี่ยวข้ องกับกระบวนการพัฒนาซอฟต์ แวร์ Pressman [1] กล่ าวว่ า กระบวนการซอฟต์ แวร์ นัน้ หมายถึงกรอบของงานต่ าง ๆ ที่จาเป็ นสาหรับการพัฒนาซอฟต์ แวร์ ท่ มี ีคุณภาพสูง คาว่ ากระบวนการซอฟต์ แวร์ นีม้ ีความหมายทัง้ เหมือนกันและแตกต่ างกันจากคาว่ าวิศวกร รมซอฟต์ แวร์ คาว่ ากระบวนการซอฟต์ แวร์ นัน้ หมายถึงแนวทางที่ใช้ ระหว่ างการดาเนินการวิศวกรรมกับ ซอฟต์ แวร์ แต่ คาว่ าวิศวกรรมซอฟต์ แวร์ นัน้ รวมเทคโนโลยีต่าง ๆ ที่นามาใช้ ในกระบวนการซอฟต์ แวร์ ตลอดจนเครื่องมือต่ าง ๆ ทางด้ านวิศวกรรมซอฟต์ แวร์ ด้วย กระบวนการซอฟต์ แวร์ ของบริษัทและหน่ วยงานต่ าง ๆ นัน้ มีความแตกต่ างกันมาก สุดแท้ แต่ ความสามารถในการบริหารงานซอฟต์ แวร์ และ ของบุคลากรผู้พัฒนาซอฟต์ แวร์ บริษัทและหน่ วยงานบางแห่ งสามารถพัฒนาซอฟต์ แวร์ ได้ ดี แต่ บริษัทและหน่ วยงานอื่นที่มีสมบัตคิ ล้ ายกันในแทบจะทุกด้ านกลับไม่ สามารถพัฒนาซอ ฟต์ แวร์ ได้ ดีเท่ า ด้ วยเหตุนีจ้ ึงเกิดคาถามว่ าเหตุใดจึงเป็ นเช่ นนี ้ มีปัจจัยอะไรหรือที่บงการให้ เกิดความแตกต่ างเช่ นนี ้ เพื่อตอบคาถามนี ้ เมื่อเดือนพฤศจิกายน ปี 1986 สถาบัน SEI ร่ วมกับ Mitre Corporation ได้ เริ่มดาเนินการพัฒนาแบบจาลองสาหรับใช้ ในการระบุว่าหน่ วยงานต่ าง ๆ มีความสามารถในการพัฒนาซอฟต์ แวร์ ถงึ ระดับไหนบ้ าง [3] ในเดือนกันยายนปี ต่ อมา สถาบันได้ ประกาศคาอธิบายสัน้ ๆ เกี่ยวกับกรอบงานสาหรับวัดความเจริญก้ าวหน้ าในด้ านการพัฒนาซอฟต์ แวร์ ออกมาให้ ผ้ ู สนใจรับทราบ การวัดนีใ้ ช้ วิธีการสามแบบ แบบแรกเรียกว่ าการประเมินกระบวนการซอฟต์ แวร์ ซ่ งึ เป็ นการใช้ ทีมงานซอฟต์ แวร์ มืออา ชีพที่ได้ รับการฝึ กมาเป็ นพิเศษในการกาหนดระดับความก้ าวหน้ าด้ านซอฟต์ แวร์ ขององค์ การ มาศึกษาประเด็นสาคัญต่ าง ๆ เกี่ยวกับการพัฒนาซอฟต์ แวร์ ท่ อี งค์ การกาลังประสบอยู่ แบบที่สองคือ การประเมินความสามารถของซอฟต์ แวร์ เป็ นการใช้ ทีมงานซอฟต์ แวร์ มืออาชีพในการประเมินหาผู้รับจ้ างพัฒนาซอฟต์ แวร์ ท่ มี ีควา มสามารถมากพอที่จะรั บงานดูแลกระบวนการซอฟต์ แวร์ ท่ อี งค์ การกาลังดาเนินงานอยู่ และ Eau2547.doc 13 แบบที่สามเป็ นการใช้ แบบสอบถามที่มีคาตอบสาหรับประเมินค่ าห้ าระดับในการประเมิน ความเจริญก้ าวหน้ าของกระบวนการซอฟต์ แวร์ หลังจากใช้ กรอบงานข้ างต้ นในการวัดความเจริญก้ าวหน้ าของกระบวนการซอฟต์ แวร์ เป็ น เวลานานถึงสี่ปี ในที่สุดสถาบันก็สามารถจัดทาแบบจาลองความเจริญก้ าวหน้ าทางด้ านความสามารถทาง ด้ านซอฟต์ แวร์ ขององค์ การออกมาได้ ในปี 1991 แบบจาลองนีเ้ รียกย่ อ ๆ ว่ า CMM (ย่ อมาจาก Capability Maturity Model for Software) CMM ช่ วยให้ หน่ วยงานที่ทางานด้ านซอฟต์ แวร์ มีแนวทางสาหรับควบคุมกระบวนการในการพัฒ นาและดูแลรั กษาซอฟต์ แวร์ และ แนวทางสาหรับทาให้ หน่ วยงานก้ าวหน้ าขึน้ ไปถึงระดับชัน้ ที่มีความเป็ นเลิศทางด้ านวิศวก รรมซอฟต์ แวร์ และ การจัดการซอฟต์ แวร์ แบบจาลองนีช้ ่ วยให้ หน่ วยงานซอฟต์ แวร์ สามารถเลือกกลยุทธ์ ในการปรับปรุงกระบวนกา รซอฟต์ แวร์ โดยการกาหนดว่ าปั จจุบันหน่ วยงานมีระดับความเจริญก้ าวหน้ าอยู่ขัน้ ใด แล้ วจึงกาหนดประเด็นต่ าง ๆ ที่มีความสาคัญต่ อการปรั บปรุงคุณภาพและกระบวนการซอฟต์ แวร์ โดยวิธีให้ ความสนใจเฉพาะในประเด็นที่สาคัญบางเรื่องจะช่ วยให้ หน่ วยงานปรับปรุงกระ บวนการซอฟต์ แวร์ ได้ อย่ างต่ อเนื่องโดยตลอด และ สามารถยกระดับความเจริญก้ าวหน้ าได้ อย่ างยั่งยืน หลักการพื ้นฐานเกี่ยวกับความเจริญก้ าวหน้ าของกระบวนการ ได้ กล่ าวไปแล้ วว่ า กระบวนการซอฟต์ แวร์ คือแนวทาง อันรวมทัง้ กิจกรรม วิธีการ และ วิธีปฏิบัตใิ นการพัฒนาและบารุงรักษาซอฟต์ แวร์ ในข้ อเสนอของ CMM ได้ ให้ รวมงานที่เกี่ยวข้ องกับซอฟต์ แวร์ เอาไว้ ในกระบวนการซอฟต์ แวร์ ด้วย [3] นั่นคือ แผนงานโครงการ เอกสารการออกแบบระบบ ตัวคาสั่งในโปรแกรม รายการทดสอบ และ คู่มือผู้ใช้ เมื่อหน่ วยงานหรือองค์ การเจริญก้ าวหน้ าขึน้ กระบวนการซอฟต์ แวร์ จะมีความชัดเจนมาก ขึน้ และ สามารถนาไปใช้ งานได้ อย่ างสอดคล้ องต้ องกันทัง้ หน่ วยงาน คาว่ า ความสามารถของกระบวนการซอฟต์ แวร์ (Software process capability) หมายความถึง พิสัยของผลลัพธ์ ท่ อี าจเกิดขึน้ ได้ จากการดาเนินงานตามกระบวนการซอฟต์ แวร์ นี ้ ความสามารถของกระบวนการซอฟต์ แวร์ ของหน่ วยงานแห่ งหนึ่งสามารถใช้ พยากรณ์ ได้ ว่ าจะเกิดผลลัพธ์ อย่ างไรกับโครงการซอฟต์ แวร์ ต่อไปของหน่ วยงานนัน้ Eau2547.doc 14 คาว่ า ผลสาเร็จของกระบวนการซอฟต์ แวร์ (Software process performance) หมายถึงผลที่เกิดขึน้ จริง ๆ จากการใช้ กระบวนการซอฟต์ แวร์ ดังนัน้ ผลสาเร็จของกระบวนการซอฟต์ แวร์ จึงหมายถึงผลลัพธ์ ท่ เี กิดขึน้ ส่ วนความสามารถของกระบวนการซอฟต์ แวร์ หมายถึงผลลัพธ์ ท่ คี าดหมายได้ ว่าจะเกิดขึน้ คาว่ า ความเจริญก้ าวหน้ าของกระบวนการซอฟต์ แวร์ (Software process maturity) หมายถึงระดับในการกาหนด จัดการ วัดขนาด ควบคุม และ ดาเนินการให้ ได้ ผลซึ่งกระบวนการซอฟต์ แวร์ หนึ่ง ๆ ความเจริญก้ าวหน้ านัน้ หมายถึงศักยภาพในการเติบโตทางด้ านความสามารถ และ เป็ นเครื่องชีว้ ัดทัง้ ความร่ ารวยของกระบวนการซอฟต์ แวร์ ขององค์ การ และ ความสม่าเสมอในการใช้ กระบวนการซอฟต์ แวร์ นีใ้ นโครงการซอฟต์ แวร์ ต่าง ๆ ทัง้ องค์ การ CMM กับ การพัฒนาซอฟต์แวร์ (ต่อ) ระดับความเจริญก้ าวหน้ าของกระบวนการซอฟต์ แวร์ นักวิชาการของสถาบัน SEI เชื่อว่ าความเจริญก้ าวหน้ าทางด้ านซอฟต์ แวร์ นัน้ ไม่ สามารถจะเนรมิตรให้ เกิดขึน้ ในพริบ ตา แต่ จะเกิดขึน้ ได้ จากการปรับปรุงการทางานไปทีละน้ อย ๆ นักซอฟต์ แวร์ ของ SEI ใช้ หลักการด้ านคุณภาพของนักวิชาการด้ านคุณภาพที่มีช่ ือเสียงของโลก อาทิ วอลเตอร์ ชิวฮาร์ ต, เอ็ดเวิรด เดมิง, โจเซฟ ฮูรัน, และ ฟิ ลิป ครอสบี ในการกาหนดขัน้ ตอนหรื อระดับความเจริญก้ าวหน้ าของกระบวนการซอฟต์ แวร์ โดยแบ่ งออกเป็ นห้ าระดับดังนี ้ ระดับที่ 1 ระดับตัง้ ต้ น (Initial level) หน่ วยงานที่อยู่ในระดับนีย้ ังไม่ สามารถสร้ างสภาวะที่ม่ ันคงในการพัฒนาซอฟต์ แวร์ ได้ หน่ วยงานยังมีความยากลาบากในการจัดกระบวนการซอฟต์ แวร์ ท่ เี ป็ นระบบ ส่ งผลให้ เกิดวิกฤติการณ์ ในการทางานอยู่เสมอ เมื่อเกิดวิกฤติการณ์ ขนึ ้ ผู้พัฒนาซอฟต์ แวร์ ก็จะเลิกทางานตามที่วางแผนไว้ แล้ วรีบด่ วนเขียนคาสั่งและทดสอบแทน ความสาเร็จของการพัฒนาซอฟตแวร์ ในระดับนีข้ นึ ้ อยู่กับประสบการณ์ และความสามารถ ของหัวหน้ าโครงการ และ ทีมีงานที่มีประสิทธิผล หากได้ หัวหน้ าโครงการที่มีความสามารถ และกล้ าคิดกล้ าทา มาปรับปรุงการพัฒนาซอฟต์ แวร์ ก็จะทาให้ หน่ วยงานมีกระบวนการซอฟต์ แวร์ ท่ ดี ีขนึ ้ แต่ ถ้าหากหัวหน้ าโครงการเช่ นนีล้ าออกไปหน่ วยงานก็จะกลับไปสู่ระดับเดิม Eau2547.doc 15 เพราะไม่ ว่าจะใช้ หลักการวิศวกรรมที่เยี่ยมขนาดไหน แต่ ถ้าหากกระบวนการจัดการยังไม่ ดีพอ ความพยายามที่จะปรับปรุ งก็ไร้ ประโยชน์ หน่ วยงานที่อยู่ในระดับนีอ้ าจพัฒนาซอฟต์ แวร์ ได้ สาเร็จ แต่ มักจะประสบกับปั ญหายุ่งเหยิง และการพัฒนาซอฟต์ แวร์ มักจะใช้ เวลาและงบประมาณเกินที่กาหนดไว้ อาจกล่ าวได้ ว่าความสามารถที่ระดับนีเ้ ป็ นความสามารถของบุคคลมากกว่ าขององค์ การ ระดับที่ 2 ระดับทาซา้ ได้ (Repeatable level) หน่ วยงานที่อยู่ในระดับนีเ้ ริ่มมีนโยบายในการบริหารจัดการโครงการซอฟต์ แวร์ และมีการ กาหนดขัน้ ตอนการนานโยบายไปใช้ การวางแผนและจัดการโครงการใหม่ มักจะขึน้ กับประสบการณ์ จากโครงการที่คล้ ายกัน ความสามารถของกระบวนการนัน้ เกิดจากการนาขัน้ ตอนพืน้ ฐานทางด้ านการบริหารโครง การมาใช้ กระบวนการที่ได้ ผลมีลักษณะเป็ นงานที่มีการจัดทาเอกสาร ควบคุม มีการฝึ กอบรม มีการวัดผล และ สามารถปรับปรุงให้ ดีขนึ ้ ได้ โครงการในระดับนีม้ ีการควบคุมและติดตามการทางานตามภารกิจต่ าง ๆ ที่กาหนดในแผน มีการดูแลค่ าใช้ จ่ายต่ าง ๆ ว่ าเป็ นไปตามที่กาหนดหรื อไม่ เราอาจกล่ าวได้ ว่าลักษณะของระดับนีก้ ็คือใช้ ผลสาเร็จของโครงการที่ผ่านมาเป็ นตัวอย่ าง มีการกาหนดมาตรฐานโครงการ และมีการจัดรู ปแบบองค์ กรให้ งานโครงการดาเนินไปได้ ดี ระดับที่ 3 ระดับชัดเจน (Defined Level) ในหน่ วยงานที่อยู่ระดับนี ้ จะมีการบันทึกทาเอกสารเกี่ยวกับกระบวนการมาตรฐานในการพัฒนาและบารุงรักษาซอ ฟต์ แวร์ เอาไว้ อีกทัง้ ยังมีการทาเอกสารเกี่ยวกับงานวิศวกรรมซอฟต์ แวร์ และกระบวนการจัดการต่ าง ๆ ด้ วย ที่สาคัญคือก็คือกระบวนการเหล่ านีจ้ ะถูกนามาผสมรวมกันเป็ นเนือ้ เดียว ในงาน CMM นัน้ ถือว่ ากระบวนการมาตรฐานนัน้ เป็ นเรื่องที่สาคัญมากของทัง้ องค์ การ กระบวนการในระดับ 3 นีช้ ่ วยให้ หัวหน้ าโครงการซอฟต์ แวร์ และลูกทีมทางานได้ อย่ างมีประสิทธิผล หน่ วยงานสามารถใช้ แนวทางของวิศวกรรมซอฟต์ แวร์ ได้ ผลขึน้ เมื่อมีการกาหนดมาตรฐา นกระบวนการซอฟต์ แวร์ นอกจากนีห้ น่ วยงานอาจจัดตัง้ กลุ่มกระบวนการวิศวกรรมซอฟต์ แวร์ ขนึ ้ เพื่อรับผิดชอบงา นต่ าง ๆ ที่เกี่ยวกับกระบวนการซอฟต์ แวร์ ของหน่ วยงานด้ วย Eau2547.doc 16 ที่สาคัญก็คือมีการจัดฝึ กอบรมอย่ างกว้ างขวางเพื่อให้ ผ้ ูบริหารโครงการและลูกทีมมีความ รู้ และทักษะที่สามารถทางานที่กาหนดได้ ดี โครงการต่ าง ๆ ที่ทาในระดับนีจ้ ะช่ วยให้ หน่ วยงานปรับเปลี่ยนกระบวนการซอฟต์ แวร์ ของตนตามลักษณ ะพิเศษของโครงการได้ กระบวนการซอฟต์ แวร์ ท่ ปี รั บเปลี่ยนแล้ วนี ้ ทาง CMM เรียกว่ ากระบวนการซอฟต์ แวร์ ท่ ชี ัดเจน (Defined software process) (ความหมายของคานีค้ งจะต้ องให้ เทียบเคียงกับคาว่ า Well-defined function ทางคณิตศาสตร์ ซึ่งราชบัณฑิตยสถานได้ กาหนดให้ ใช้ ศัพท์ ไทยว่ า ฟั งก์ ชันที่แจ่ มชัด) กระบวนการซอฟต์ แวร์ ท่ ชี ัดเจนจะต้ องมีกระบวนการทางวิศวกรรมซอฟต์ แวร์ และกระบว นการจัดการที่แจ่ มชัดด้ วย และจะแสดงได้ ด้วยการมีเงื่อนไขที่ชัดเจน มีมาตรฐานและวิธีการสาหรับทางานต่ าง ๆ มีกลไกในการตรวจสอบ มีการกาหนดผลลัพธ์ และ เงื่อนไขการจบโครงการ โดยที่โครงการพัฒนาซอฟต์ แวร์ มีความชัดเจนเช่ นนี ้ ฝ่ ายบริหารจึงวางใจได้ ว่าจะสามารถตรวจสอบความก้ าวหน้ าในการดาเนินงานโครงการไ ด้ ตลอดเวลา เราอาจกล่ าวได้ ว่าความสามารถในกระบวนการซอฟต์ แวร์ ระดับนีก้ ็คือการมีมาตรฐานแล ะความคล้ องจองกันทัง้ หน่ วยงาน ระดับที่ 4 ระดับจัดการ (Managed Level) หน่ วยงานที่มีความสามารถอยู่ในระดับนีส้ ามารถกาหนดคุณภาพในเชิงจานวนให้ แก่ ซอฟ ต์ แวร์ และกระบวนการซอฟต์ แวร์ ได้ หน่ วยงานสามารถวัดคุณภาพและผลผลิตของกระบวนการซอฟต์ แวร์ สาคัญ ๆ ของทุกโครงการได้ โดยถือว่ าเป็ นส่ วนหนึ่งของกระบวนการวัดผลงานขององค์ การ มีการจัดทาฐานข้ อมูลสาหรั บบันทึกและวิเคราะห์ ข้อมูลเกี่ยวกับการใช้ กระบวนการซอฟต์ แวร์ ท่ ชี ัดเจน การควบคุมโครงการต่ าง ๆ ทาได้ โดยการพยายามทาให้ ผลการดาเนินงานมีความสม่าเสมอมากขึน้ มีการกาหนดความเสี่ยงในการพัฒนาระบบและควบคุมความเสี่ยงให้ ลดน้ อยลง เราอาจกล่ าวได้ ว่าหน่ วยงานที่ม่ ีการพัฒนาซอฟต์ แวร์ อยู่ในระดับนีค้ ือหน่ วยงานที่สามารถ วัดผลและพยากรณ์ ผลที่จะเกิดในการทางานโครงการซอฟต์ แวร์ ได้ อย่ างแม่ นยา สามารถพยากรณ์ แนวโน้ มและคุณภาพของซอฟต์ แวร์ ได้ ดี ในเมื่อสภาวะการทางานค่ อนข้ างลงตัว เมื่อมีโครงการแปลก ๆ เข้ ามาให้ ทา หน่ วยงานก็สามารถปรับกระบวนการได้ เป็ นอย่ างดี ระดับที่ 5 Eau2547.doc 17 ระดับเหมาะที่สุด (Optimizing Level) หน่ วยงานที่อยู่ระดับนีเ้ ป็ นหน่ วยงานที่เน้ นในด้ านการปรั บปรุ งกระบวนการอยู่ตลอดเวลา หน่ วยงานมีวิธีการกาหนดจุดอ่ อนและจุดแข็งของกระบวนการในเชิงรุก โดยมีเป้ าหมายในการป้ องกันไม่ ให้ เกิดข้ อบกพร่ องขึน้ หน่ วยงานใช้ ข้อมูลเกี่ยวกับประสิทธิผลของกระบวนการซอฟต์ แวร์ ในการวิเคราะห์ ต้นทุน และกาไรของเทคโนโลยีใหม่ ๆ เพื่อใช้ เสนอการเปลี่ยนแปลงกระบวนการซอฟต์ แวร์ ของหน่ วยงาน มีการกาหนดว่ านวัตกรรมใดเหมาะที่สุดสาหรับหน่ วยงาน จากนัน้ ก็ถ่ายทอดไปใช้ ทงั ้ องค์ การ ทีมงานซอฟต์ แวร์ ในระดับนีท้ าหน้ าที่วิเคราะห์ ข้อบกพร่ องเพื่อหาสาเหตุ มีการประเมินกระบวนการซอฟต์ แวร์ เพื่อป้ องกันไม่ ให้ เกิดข้ อบกพร่ องซา้ อีกและนาความ รู้ ท่ ไี ด้ นัน้ ไปถ่ ายทอดให้ ทีมงานพัฒนาซอฟต์ แวร์ ทราบ นอกจากนัน้ มีการวิเคราะห์ ความสูญเสียในการดาเนินงานและพยายามลดไม่ ให้ เกิดความ สูญเสียเหล่ านัน้ ด้ วย หน่ วยงานที่มีความสามารถในระดับนีค้ ือหน่ วยงานที่พยายามปรั บปรุ งตนอยู่ตลอดเวลา การปรับปรุงนีม้ ีทงั ้ ที่ค่อยเป็ นค่ อยไป และ การปรับปรุงโดยการนานวัตกรรมใหม่ ๆ มาใช้ กลุ่มกระบวนการหลัก สถาบัน SEI ได้ กาหนดกลุ่มกระบวนการหลัก (Key Process Area หรือ KPA) สาหรับระดับความสามารถแต่ ละระดับเอาไว้ ด้วย กลุ่มกระบวนการหลักเหล่ านีใ้ ช้ อธิบายฟั งก์ ชันต่ าง ๆ ทางด้ านวิศวกรรมซอฟต์ แวร์ ท่ จี ะต้ องมีในแต่ ละระดับ การกาหนดกลุ่มกระบวนการหลักแต่ ละรายการจะต้ องจาแนกตามสมบัตติ ่ อไปนี ้       เป้ าหมาย วัตถุประสงค์ หลักที่ KPA แต่ ละรายการจะต้ องบรรลุให้ ได้ ข้ อตกลง ข้ อกาหนดที่ระบุให้ หน่ วยงานต้ องดาเนินงานให้ บรรลุเป้ าหมาย และเป็ นการยืนยันว่ าจะพยายามทาตามเป้ าหมาย ความสามารถ สมบัตทิ ่ จี าเป็ นจะต้ องมีทงั ้ ทางด้ านองค์ กรและในเชิงเทคโนโลยีเพื่อให้ หน่ วยงาน ดาเนินงานตามข้ อตกลง กิจกรรม ภารกิจที่จาต้ องทาเพื่อให้ บรรลุ KPA วิธีการตรวจการดาเนินงาน แนวทางในการตรวจกิจกรรมว่ าดาเนินไปเช่ นใด วิธีการตรวจสอบผลการดาเนินงาน แนวทางในการตรวจสอบการดาเนินงาน KPA ว่ าดาเนินการได้ ถูกต้ องเหมาะสม Eau2547.doc 18 กลุ่มกระบวนการหลักที่ได้ กาหนดขึน้ สาหรับการดาเนินงานเกี่ยวกับซอฟต์ แวร์ ในแต่ ละ ระดับความสามารถมีดังต่ อไปนี ้ ระดับที่ 1  ไม่ มี KPA ระดับที่ 2       Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planning Requirements management ระดับที่ 3        Peer reviews Intergroup coordination Software product engineering Integrated software management Training program Organization process definition Organization process focus ระดับที่ 4   Software quality management Quantitative process management ระดับที่ 5    Process change management Technology change management Defect prevention Eau2547.doc 19 สรุป ในที่นีผ้ มคงไม่ ต้องสรุปอะไรมาก ท่ านผู้อ่านคงจะเห็นแล้ วว่ าการจะไต่ ระดับขึน้ ไปสู่ความเปนเลิศในด้ านการพัฒนาซอฟต์ แ วร์ นัน้ ไม่ ใช่ เรื่ องง่ ายเลย และเมื่อพิจารณากลุ่มกระบวนการหลักที่เราจะต้ องดาเนินการแล้ ว จะพบเห็นว่ าประเด็นสาคัญของการพัฒนาซอฟต์ แวร์ นัน้ ไม่ ได้ อยู่ท่ ดี ้ านเทคนิคแต่ อย่ างไร หากอยู่ท่ กี ระบวนการจัดการมากกว่ า หากหน่ วยงานใดมีผ้ ูบริหารที่เอาใจใส่ ในเรื่ องคอมพิวเตอร์ และสนใจต้ องการพัฒนาซอฟต์ แวร์ ท่ มี ีคุณภาพ ตลอดจนได้ กาหนดวิธีการและขัน้ ตอนในการบริหารงานในส่ วนนีอ้ ย่ างเป็ นระบบได้ แล้ ว หน่ วยงานนัน้ ก็มีโอกาสเลื่อนระดับชัน้ CMM ขึน้ ไปสู่ความเป็ นเลิศได้ แต่ หน่ วยงานใดไม่ มีผ้ ูบริหารที่สนใจด้ านนีเ้ ลย คงมีแต่ เพียงนักคอมพิวเตอร์ เท่ านัน้ หน่ วยงานเช่ นนีก้ ็คงจะไต่ ระดับได้ เพียงแค่ ระดับหนึ่งหรือสองอย่ างแน่ นอน ก่ อนจบ มีข่าวดีท่ ตี ้ องการเรี ยนให้ ท่านผู้อ่านทราบว่ า โครงการจัดตัง้ เขตอุตสาหกรรมซอฟต์ แวร์ ได้ เห็นความสาคัญของการพัฒนาความเป็ นเลิ ศในด้ านซอฟต์ แวร์ ของหน่ วยงานต่ าง ๆ ในไทย ดังนัน้ จึงมีดาริท่ จี ะเชิญให้ บุคลากรจากสถาบัน SEI เดินทางเข้ ามาถ่ ายทอดความรู้ และประสบการณ์ ในด้ านนีแ้ ก่ นักซอฟต์ แวร์ ไทย รู ปแบบการจัดและเนือ้ หาจะเป็ นเช่ นใด กรุ ณาติดต่ อสอบถามได้ ท่ ี คุณขวัญเดือน ตันติศิริวัฒน์ เขตอุตสาหกรรมซอฟต์ แวร์ ประเทศไทย โทรศัพท์ 583-9992 ต่ อ 1421 โทรสาร 583-2884…และอีเมล์ khwanduen@swpark.org สวัสดีครับ บรรณานุกรม 1. Pressman, R.S., Software Engineering: A practitioner's Approach, Fourth Edition, McGraw-Hill, Singapore, 1997. 2. SEI, About the SEI - Welcome, http://www.sei.cmu.edu/about/about.html 3. Paulk, M.C., et al, The Capability Maturity Model for Software, Version 1.1, Technical Report, CMU/SEI-93-TR-024, 1993. Eau2547.doc 20 What is the CMM?     A common-sense application of process management and quality improvement concepts to software develpment and maintenance A community-developed guide A model for organizational improvement The underlying structure for reliable and consistent CMM-based appraisal methods Capability Maturity Model for Software The CMM provides a framework for organizing these evolutionary steps into five maturity levels that define an ordinal scale for measuring the maturity of an organization's software process and for evaluating its software process capability. Each level consists of key process areas which identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important for enhancing process capability. The CMM levels picture is shown on the above and described on the following: 1. Initial Level- Process unpredictable and poorly controlled Eau2547.doc 21 The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics. Except for Level 1, each maturity level is decomposed into several key process areas that indicate the areas an organization should focus on to improve its software process. 2. Repeatable Level - Projects can repeat previously mastered tasks Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications. The key process areas at Level 2 focus on the software project's concerns related to establishing basic project management controls. They are Requirements Management, Software Project Planning, Software Project Tracking and Oversight, Software Subcontract Management, Software Quality Assurance, and Software Configuration Management. 3. Defined Level - Process characterized, fairly well understood The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software. The key process areas at Level 3 address both project and organizational issues, as the organization establishes an infrastructure Eau2547.doc 22 that institutionalizes effective software engineering and management processes across all projects. They are Organization Process Focus, Organization Process Definition, Training Program, Integrated Software Management, Software Product Engineering, Intergroup Coordination, and Peer Reviews. 4. Managed Level - Process measured and controlled Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled. The key process areas at Level 4 focus on establishing a quantitative understanding of both the software process and the software work products being built. They are Quantitative Process Management and Software Quality Management. 5. Optimizing Level - Focus on process improvement Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies . The key process areas at Level 5 cover the issues that both the organization and the projects must address to implement continual, measurable software process improvement. They are Defect Prevention, Technology Change Management, and Process Change Management. What is a Project Plan? Eau2547.doc 23 The project plan is the controlling document to manage an Information Management/Information Technology (IM/IT) project. The project plan describes the: Interim and final deliverables the project will deliver, Managerial and technical processes necessary to develop the project deliverables, Resources required to deliver the project deliverables, and Additional plans required to support the project. Why create a Project Plan? Documenting the decisions is essential. As you record, gaps appear and inconsistencies protrude. Creating the project plan usually requires hundreds of minidecisions and these bring clarity to the project. The project plan communicates the decisions to others. Often what we assume is common knowledge is unknown by other members of the team. Fundamentally, the project manager's goal is to keep everyone progressing in the same direction and communication is essential to achieve this goal. The project plan makes communicating a lot easier. The project plan is a wealth of information as well as a checklist. By reviewing the project plan, as often as is required, the project manager knows where the project is to identify what correction action or changes of emphasis or shifts in direction are needed. 80% of a project manager's time is spent on communication: hearing, reporting, teaching, counselling, and encouraging. The other 20% is spent on activities where the project manager needs information that is data-based. The project plan is a critical set of documents that should meet this need. The job of the project manager is to develop a project plan and to accomplish it. Only the written project plan is precise and communicable. The project plan consists of documents on who, what, why, when, where, how and how much. The project plan Eau2547.doc 24 encapsulates much of the project manager's work. If their comprehensive and critical nature is recognized in the beginning, the manager can approach them as friendly tools rather than annoying overhead. The project managers can set the direction much more crisply and quickly by doing so. Is the Project Plan Applicable to all IM/IT Projects? The project plan is applicable to all types of IM/IT projects regardless of size, complexity or criticality. Not all projects are concerned with developing source code for a new software product. Projects can cover: Business cases, Feasibility studies and the definition of IM/IT requirements, Specific phases of an IM/IT product life cycle, Major modifications to existing software products, and Upgrades to technical infrastructure. Smaller projects may require less formality than larger projects, but all components of the project plan should be addressed by everyIM/ITproject. Who is responsible for the Project Plan? The individual or organization responsible for the IM/IT project will be responsible for the project plan. Evolution of Project Plans One of the first activities to be completed in a project is the initial version of the project plan. Over time, as the inputs to the project are better understood, the plans will become more detailed. Each version of the project plan should be placed under configuration management, and each version should contain a schedule for subsequent updates to the project plan. What is the Project Plan Template? Eau2547.doc 25 The project plan template presents the format and content of an IM/IT project plan. The ordering of the sections is not meant to imply the order to develop the sections. The order is meant for ease of reading, presentation, and use, and not as a guide to the order of preparation of the various section. This template is based on the IEEE Std 1058-1998, IEEE Standard for Software Project Management Plans. The text within each section is for the benefit of the person writing the project plan and should be removed before the project plan is completed. The template is for project managers and other individuals who prepare and update project plans and track adherence to those plans. Tailoring the Project Plan Template Incorporate additional elements by inserting or appending sections by direct incorporation or by reference to other documents. Organizations can develop generic project plans so that projects can reuse sections that are common across the organization such as organization charts, roles and responsibilities, supporting processes, and infrastructure allowing projects to focus on project-unique elements such as requirements, schedule, budget, etc. References PPTO-PS-001 Project Management Process PPTO-PS-002 Project Planning Process PPTO-PS-003 Project Tracking and Oversight Process IEEE Std 1058-1998, IEEE Standard for Software Project Management Plans. Watts S. Humphrey. Managing the Software Process. Addison-Wesley, Reading, Mass., 1989. Contributors Eau2547.doc 26 The Project Planning, Tracking, and Oversight (PPTO) Working Group of the Enhanced Management Framework (EMF) of the Chief Information Officer Branch (CIOB) of the Treasury Board of Canada Secretariat (TBS) developed this document. The following individuals contributed to the development of this document: Linda Albert Revenue Canada Vern French Prior Mark Jennings Department of National Defence Debbie Jones Treasury Board of Canada Secretariat Roy Mundt Public Works and Government Services Canada Debbie Sleeman Citizenship and Immigration Canada Raymond Vilbikaitis Prior Document Change Control Revision Number Date of Issue Author(s) Brief Description of Change 0.1 1999-07-23 EMF/PPTO Initial Draft 0.2 1999-07-30 EMF-PPTO Updates from first level review. 0.3 1999-08-09 TBS Client Services Updates to comply with TBS Document/Web standards 0.4 1999-08-12 Eau2547.doc 27 EMF-PPTO Updates from PPTO Working Group review. 1.0 1999-11-10 EMF-PPTO First Draft หัวข้ อ TOR Project Plan TEMPLET 1. Project Overview This section of the IM/IT Project Management Plan provides an overview of the purpose, scope and objectives of the project for which the Plan has been written, the project assumptions and constraints, a list of project deliverables, a summary of the project schedule and budget, and the plan for evolving the IM/IT Project Management Plan. 1.1 Purpose, Scope, and Objectives Define the purpose and scope of the project. Describe any considerations of scope or objectives to be excluded from the project or the deliverables. Ensure that the statement of scope is consistent with similar statements in the business case, the project charter and any other relevant system-level or business-level documents. Identify and describe the business or system needs to be satisfied by the project. Provide a concise summary of: the project objectives, the deliverables required to satisfy the project objectives, and the methods by which satisfaction of the objectives will be determined. Describe the relationship of this project to other projects. Eau2547.doc 28 If appropriate, describe how this project will be integrated with other projects or ongoing work processes. Provide a reference to the official statement of project requirements (e.g.: in the business case or the project charter). 1.2 Assumptions, Constraints and Risks Describe the assumptions on which the project is based. Describe the imposed constraints and risks on the project such as: schedule, budget, resources, quality, software to be reused, existing software to be incorporated, technology to be used, and external interfaces. 1.3 Project Deliverables Identify and list the following, as required to satisfy the terms of the project charter or contract: project deliverables (either directly in this Plan, or by reference to an external document), delivery dates, delivery location, ands quantities required. Specify the delivery media. Specify any special instructions for packaging and handling. 1.4 Schedule and Budget Summary Provide a summary of the schedule and budget for the IM/IT project. Eau2547.doc 29 Restrict the level of detail to an itemization of the major work activities and supporting processes (e.g.: give only the top level of the work breakdown structure). 1.5 Evolution of the Plan Identify the compliance of this Plan to any standards. The structure of this Project Plan is in compliance with the recommendations of IEEE Std 1058-1998. Specify the plans for producing both scheduled and unscheduled updates to this Plan. Specify how the updates to this Plan shall be disseminated. Specify how the initial version of this Plan shall be placed under configuration management. Specify how changes to this Plan shall be controlled after its issue. 1.6 References Provide a complete list of all documents and other sources of information referenced in this Plan. Identify each referenced document by title, report number, date, author and publishing organization. Identify other referenced sources of information, such as electronic files, using unique identifiers such as path/name, date and version number. Identify and justify any deviations from the referenced standards or policies. 1.7 Definitions and Acronyms Define, or provide references to documents or annexes containing the definition of all terms and acronyms required to properly understand this Plan. Eau2547.doc 30 2. Project Organization 2.1 External Interfaces Describe the organizational boundaries between the project and external entities. Identify, as applicable: the parent organization, the customer, subcontracted organizations, and other organizational entities that interact with the project. Use organizational charts or diagrams to depict the project's external interfaces. 2.2 Internal Structure Describe the internal structure of the project organization. Describe the interfaces among the units of the IM/IT development team. Describe the interfaces between the project and organizational entities that provide supporting processes, such as configuration management, quality assurance, and verification and validation. Use organizational charts or diagrams to depict the lines of authority, responsibility and communication within the project. 2.3 Roles and Responsibilities Identify and state the nature of each major work activity and supporting process. Identify the organizational units that are responsible for those processes and activities. Consider using a matrix of work activities and supporting processes vs. organizational units to depict project roles and responsibilities. Eau2547.doc 31 หัวข้ อการจัดทาโครงการ หรื อ TOR Project Plan Template http://www.cio-dpi.gc.ca/emf-cag/ppto-gtpss/projplantemplate/ppt-mpptb_e.asp Table of Contents 1. Project Overview 1.1 Purpose, Scope, and Objectives 1.2 Assumptions and Constraints 1.3 Project Deliverables 1.4 Schedule and Budget Summary 1.5 Evolution of the Plan 1.6 References 1.7 Definitions and Acronyms 2. Project Organization 2.1 External Interfaces 2.2 Internal Structure 2.3 Roles and Responsibilities 3. Managerial Process Plans 3.1 Start-up Plan 3.1.1 Estimates 3.1.2 Staffing 3.1.3 Resource Acquisition 3.1.4 Project Staff Training 3.2 Work Plan 3.2.1 Work Breakdown Structure 3.2.2 Schedule Allocation 3.2.3 Resource Allocation 3.2.4 Budget Allocation 3.3 Project Tracking Plan 3.3.1 Requirements Management 3.3.2 Schedule Control 3.3.3 Budget Control Eau2547.doc 32 3.3.4 Quality Control 3.3.5 Reporting 3.3.6 Project Metrics 3.4 Risk Management Plan 3.5 Project Closeout Plan 4. Technical Process Plans 4.1 Process Model 4.2 Methods, Tools, and Techniques 4.3 Infrastructure 4.4 Product Acceptance 5. Supporting Process Plans 5.1 Configuration Management 5.2 Verification and Validation 5.3 Documentation 5.4 Quality Assurance 5.5 Reviews and Audits 5.6 Problem Resolution 5.7 Subcontractor Management 5.8 Process Improvement 6. Additional Plans Annex A Annex B Project Management Methodology (PMM) Varying project management methodologies have been used and developed by the State of Michigan based on the applicable project. The Project Management Methodology is available for large, complex projects; the PMM Express is available for smaller, less complex projects; and the Project Management Institute Project Management Book of Knowledge is available as a guiding foundation for all of the State of Michigan methodologies. Eau2547.doc 33 Project Management Methodology (PMM) The State of Michigan's Project Management Methodology (PMM) was adopted as a State standard in May 2000 and revised in May 2001 to reflect the experiences and lessons learned in using the prior release. This methodology is available for use by all state agencies. The Project Management Methodology consists of three components; the full PMM, the summarized Desk Reference, and the Project Management Templates. The PMM was developed by an advisory group composed of multiple state agency staff based on agency requirements. The PMM is revised periodically (minimally every 24 months) to reflect new processes in use in Michigan government. The next version of PMM is currently under development and is scheduled for an October 2004 release! PMM Express Project Management Methodology (PMM) Express was developed as a guide to assist in the management of smaller, less complex projects within the Department of Information Technology. PMM Express is a customized version of the State of Michigan Project Management Methodology (PMM) and schedule templates (in both Niku Workbench and MS Project). The PMM was streamlined to handle the effort/complexity level of 30 to 90 day projects. The applicable PMM templates include:  Project Charter  Project Plan  Project Status Report  Project Issue Document  Project Change Control Request, and  Post Implementation Evaluation Report (PIER) A standardized project schedule template is incorporated into PMM Express in both Niku Workbench and MS Project formats. The project schedule template contains the following major phases:  Initiation (charter development) Eau2547.doc 34     Planning (project plan development) Execution (executing the project plan, maintaining the project schedule, managing project scope changes, and managing project issues) Control (weekly status report preparation and status meetings) Closeout (validating customer expectations, documenting best practices and lessons learned, and official project sign-off) Project Management Body of Knowledge (PMBOK®) The PMBOK®, developed by the Project Management Institute, is an inclusive term that describes the sum of knowledge within the profession of project management. This document includes knowledge of proven, traditional practices which are widely applied, as well as knowledge of innovative and advanced practices which may have seen more limited use. A “Guide to The Project Management Body of Knowledge” (also called the PMBOK® Guide) identifies and describes that subset of the Project Management Body of Knowledge, which is generally accepted. Generally accepted means that the knowledge and practices described are applicable to most projects most of the time, and that there is widespread consensus about their value and usefulness. Related Documents PM Methodology Document (PDF file) PM Desk Reference (PDF file) Combined PMM Templates in MS Word Format (ZIP file) Combined PMM Templates in Rich Text Format (ZIP file) PMM Express Document PMM Express Templates (Zip file) Eau2547.doc 35 E-mail ICE CLICK HERE to view a nice graphic designed by Fred Hansen (SEI), that shows the 16 CSP being implemented in a typical software development life cycle. Table of Contents 16 CSP Supporting Information Table of Contents Eau2547.doc 36 PURPOSE PROJECT INTEGRITY 1. Adopt Continuous Risk Management 2. Estimate Cost & Schedule Empirically 3. Use Metrics to Manage 4. Track Earned Value 5. Track Defects Against Quality Targets 6. Treat People as the Most Valuable Resource CONSTRUCTION INTEGRITY 7. Adopt Life Cycle Configuration Management 8. Manage and Trace Requirements 9. Use System-based Software Design 10. Ensure Data & Database Interoperability 11. Define & Control Interfaces 12. Design Twice, Code Once 13. Assess Reuse Risks & Costs PRODUCT STABILITY AND INTEGRITY 14. Inspect Requirements & Design 15. Manage Testing as a Continuous Process 16. Compile & Smoke Test Frequently Purpose This paper outlines the 16 Critical Software PracticesTM that serve as the basis for implementing effective performance-based management of software-intensive projects. They are intended to be used by programs desiring to implement effective highleverage practices to improve their bottom-line measures-time to fielding, quality, cost, Eau2547.doc 37 predictability, and customer satisfaction-and are for CIOs, PMs, sponsoring agencies, software project managers, and others involved in software engineering. The "16 Critical Software PracticesTM for Performance-based Management" and Templates contain the 16 practices (9 best and 7 sustaining) that are the key to avoiding significant problems for software development projects. These practices have been gathered from the crucible of real-world, large-scale, software development and maintenance projects. Together they constitute a set of high-leverage disciplines that are focused on improving a project's bottom line. This document is intended to define the essential ingredients of each best and sustaining practice. These practices are the starting point for structuring and deploying an effective process for managing largescale software development and maintenance. They may be tailored to the particular culture, environment, and program phases of a program. Of course, these practices cannot help "death march" programs that are expected to deliver under impossible schedule deadlines with inadequate funding and without the required staffing with essential skills. Return to Top PROJECT INTEGRITY 1. Adopt Continuous Program Risk Management Eau2547.doc 38 Practice Essentials: a. Risk management is a continuous process beginning with the definition of the concept and ending with system retirement. b. Risk management is a program responsibility impacting on and supported by all organizational elements. c. All programs need to assign a risk officer as a focal point for risk management and maintain a reserve to enable and fund risk mitigation. d. Risk need to be identified and managed across the life of the program. e. All risks identified should be analyzed, prioritized-by impact and likelihood of occurrence-and tracked through an automated risk management tool. f. High-priority risks need to be reported to management on a frequent and regular basis. Implementation Guidelines 1. Risk management should commence prior to contract award and shall be a factor in the award process. 2. The DEVELOPER needs to establish and implement a project Risk Management Plan that, at a minimum, defines how points 3 through 8 will be implemented. The plan and infrastructure (tools, organizational assignments, and management procedures) will be agreed to by the ACQUIRER and the DEVELOPER and need to be placed under configuration management (CM). Eau2547.doc 39 3. DEVELOPER and ACQUIRER senior management should establish reporting mechanisms and employee incentives in which all members of the project staff are encouraged to identify risks and potential problems and are rewarded when risks and potential problems are identified early. The ACQUIRER needs to address risk management explicitly in its contract award fee plan, and the DEVELOPER needs to provide for the direct distribution to all employees in furtherance of establishing and maintaining a risk culture. 4. Risk identification should be accomplished in facilitated meetings attended by project personnel most familiar with the area for which risks are being identified. A person familiar with problems from similar projects in this area in the past should participate in these meetings when possible. Risk identification should include risks throughout the life cycle in at least the areas of cost, schedule, technical, staffing, external dependencies, supportability, and maintainability and should include organizational and programmatic political risks. Risk identification need to be updated at least monthly. Identified risks should be characterized in terms of their likelihood of occurrence and the impact of their occurrence. Risk mitigation activities need to be included in the project's task activity network. 5. Both the DEVELOPER and the ACQUIRER should designate and assign senior members of the technical staff as risk officers to report directly to their respective program managers and should charter this role with independent identification and management of risks across the program and grant the authority needed to carry out this responsibility. 6. Each medium-impact and high-impact risk should be described by a complete Risk Control Profile. 7. Periodically updated estimates of the cost and schedule at completion should include probable costs and schedule impact due to risk items that have not yet been resolved. Eau2547.doc 40 8. The DEVELOPER and ACQUIRER risk officers need to update the risk data and database on the schedule defined in the Risk Management Plan. All risks intended for mitigation and any others that are on the critical path and their status against the mitigation strategy should be summarized. Newly identified risks should go through the same processes as the originally identified risks. Return to Top 2. Estimate Cost and Schedule Empirically Practice Essentials 1. Initial software estimates and schedules should be looked on as high risk due to the lack of definitive information available at the time they are defined. 2. The estimates and schedules should be refined as more information becomes available. 3. At every major program review, costs-to-complete and rescheduling should be presented to identify deviations from the original cost and schedule baselines and to anticipate the likelihood of cost and schedule risks occurring. 4. All estimates should be validated using a cost model, a sanity check should be conducted comparing projected resource requirements, and schedule commitments should be made. 5. Every task within a work breakdown structure (WBS) level need to have an associated cost estimate and schedule. These tasks should be tracked using earned value. 6. All costs estimates and schedules need to be approved prior to the start of any work. Implementation Guidelines Eau2547.doc 41 1. Estimate the cost, effort, and schedule for a project for planning purposes and as a yardstick for measuring performance (tracking). Software size and cost need to be estimated prior to beginning work on any incremental release. 2. Software cost estimation should be a reconciliation between a top-down estimate (based on an empirical model; e.g., parametric, cost) and a bottom-up engineering estimate. 3. Software cost estimation should also be subjected to a "sanity check" by comparing it with industry norms and specifically with the DEVELOPER's past performance in areas such as productivity and percentage of total cost in various functions and project phases. 4. All of the software costs need to be associated with the appropriate lower-level software tasks in the project activity network. Allocate the estimated total project labor effort among all the tasks in the activity network. Return to Top 3. Use Metrics to Manage Practice Essentials 1. All programs should have in place a metrics program to monitor issues and determine the likelihood of risks occurring. 2. Metrics should be defined as part of definition of process, identification of risks or issues, or determination of project success factors. 3. All metrics definition need to include description, quantitative bounds, and expected areas of application. 4. All programs need to assign an organizational responsibility for identification, collection, analysis, and reporting of metrics throughout the program's life. Eau2547.doc 42 5. Metrics information should be used as one of the primary inputs for program decisions. 6. The metrics program needs to be continuous. Implementation Guidelines 1. Every project should have a project plan with a detail activity network that defines the process the team will follow, organizes and coordinates the work, and estimates and allocates cost and schedule among tasks. The plan should be broad enough to include each sub-process/phase. The project plan needs to include adequate measurement in each of these five categories. a. b. c. d. e. early indications of problems, the quality of the products, the effectiveness of the processes, the conformance to the process, and the provision of a basis for future estimation of cost, quality, and schedule. 2. Metrics should be sufficiently broad based. Data should be collected for each process/phase to provide insight into the above 5 categories. 3. To use these metrics effectively, thresholds need to be established for these metrics. These thresholds should be estimated initially using suggested industry norms for various project classes. Local thresholds will evolve over time, based upon experience (see 1.e above). Violation of a threshold value should trigger further analysis and decision making. 4. Examples of data, initial thresholds, and analysis of size, defect, schedule, and effort metrics can be found at http://www.qsm.com. 5. Continuous data on schedule, risks, libraries, effort expenditures, and other measures of progress should be available to all project personnel along with the latest revision of project plans. Eau2547.doc 43 Return to Top 4. Track Earned Value Practice Essentials 1. Earned value project management requires a work breakdown structure, work packages, activity networks at every WBS level, accurate estimates, and implementation of a consistent and planned process. 2. Earned value requires each task to have both entry and exit criteria and a step to validate that these criteria have been met prior to the award of the credit. 3. Earned value credit is binary with zero percent being given before task completion and 100 percent when completion is validated. 4. Earned value metrics need to be collected on a frequent and regular basis consistent with the reporting cycle required with the WBS level. (At the lowest level of the work package, the earned value reporting should never be less frequent than 2 weeks). 5. Earned value, and the associated budgets schedules, and WBS elements need to be replanned whenever material changes to the program structure are required (e.g., requirements, growth, budget changes, schedule issues, organizational change). 6. Earned value is an essential indicator and should be used as an essential metric by the risk management process. Implementation Guidelines 1. Progress towards producing the products should be measured within the designated cost and schedule allocations. 2. THE DEVELOPER should develop and maintain a hierarchical task activity network based on allocated requirements that includes the tasks for all effort that will be charged to the program. All level of effort (LOE) tasks need to have measurable milestones. All Eau2547.doc 44 tasks that are not LOE should explicitly identify the products produced by the task and have explicit and measurable exit criteria based on these products. 3. No task should have a budget or planned calendar time duration that is greater than the cost and schedule uncertainty that is acceptable for the program. The goal for task duration is no longer than two calendar weeks of effort. 4. Each task that consumes resources needs to have a cost budget allocated to it and the corresponding staff and other resources that will consume this budget. Staff resources should be defined by person hours or days for each labor category working on the task. 5. For each identified significant risk item, a specific risk mitigation/resolution task should be defined and inserted into the activity network. 6. The cost reporting system for the total project needs to segregate the software effort into software tasks so that the software effort can be tracked separately from the nonsoftware tasks. 7. Milestones for all external dependencies should be included in the activity network. 8. Earned value metrics need to be collected for each schedule level and be made available to all members of the DEVELOPER and government project teams monthly. These metrics are: a comparison of Budgeted Cost of Work Scheduled (BCWS), Budgeted Cost of Work Performed (BCWP), and Actual Cost of Work Performed (ACWP). A comparison of BCWP and ACWP, a Cost Performance Index, a Schedule Performance Index, and a To-Complete Cost Performance Index. 9. The lowest-level schedules should be statused weekly. 10. The high-level schedules should be statused at least monthly. 11. Earned value reports should be based on data that is no more than two weeks old. Return to Top Eau2547.doc 45 5. Track Defects against Quality Targets Practice Essentials 1. All programs need to have pre-negotiated quality targets, which is an absolute requirement to be met prior to acceptance by the customer. 2. Programs should implement practices to find defects early in the process and as close in time to creation of the defect as possible and should manage this defect rate against the quality target. 3. Metrics need to be collected as a result of the practices used to monitor defects, which will indicate the number of defects, defect leakage, and defect removal efficiency. 4. Quality targets need to be redefined and renegotiated as essential program conditions change or customer requirements are modified. 5. Compliance with quality targets should be reported to customers on a frequent and regular basis, along with an identification of the risk associated with meeting these targets at delivery. 6. Meeting quality targets should be a subject at every major program review. Implementation Guidelines 1. The ACQUIRER and the DEVELOPER need to establish quality targets for subsystem software depending on its requirements for high integrity. A mission-critical/safetycritical system may have different quality targets for each subsystem component. System Quality Assurance needs to monitor quality targets and report defects as per the Quality Plan. 2. Quality targets can be under change control and established at the design, coding, integration, test, and operational levels. 3. Quality targets should address the number of defects by priority and by their fix rate. Eau2547.doc 46 4. Actual quality or defects detected and removed should be tracked against the quality targets. 5. Periodic estimates of the cost and schedule at completion should be based on the actual versus targeted quality. Return to Top 6. Treat People-as the Most Important Resource Practice Essentials 1. A primary program focus should be staffing positions with qualified personnel and retaining this staff through the life of the project. 2. The program should not implement practices (e.g., excessive unpaid overtime) that will force voluntary staff turnover. 3. The staff should be rewarded for performance against expectations and program requirements. 4. Professional growth opportunities such as training should be made available to the staff. 5. All staff members need to be provided facilities, tools, and work areas adequate to allow efficient and productive performance of their responsibilities. 6. The effectiveness and morale of the staff should be a factor in rewarding management. Implementation Guidelines 1. DEVELOPER senior management needs to work to ensure that all projects maintain a high degree of personnel satisfaction and team cohesion and should identify and implement practices designed to achieve high levels of staff retention as measured by Eau2547.doc 47 industry standards. The DEVELOPER should employ focus groups and surveys to assess employee perceptions and suggestions for change. 2. DEVELOPER senior management should provide the project with adequate staff, supported by facilities and tools to develop the software system efficiently. Employee focus groups and surveys should be used to assess this adequacy. 3. The training of DEVELOPER and ACQUIRER personnel should include training according to a project training plan in all the processes, development and management tools, and methods specified in the software development plan. 4. The DEVELOPER and the ACQUIRER should determine the existing skills of all systems, software, and management personnel and provide training, according to the needs of each role, in the processes, development and management tools, and methods specified in the Software Development Plan (SDP) Return to Top CONSTRUCTION INTEGRITY 7. Adopt Life Cycle Configuration Management Practice Essentials 1. All programs, irrespective of size, need to manage information through a preplanned configuration management (CM) process. 2. CM has two aspects: formal CM, which manages customer-approved baseline information, and development CM, which manages shared information not yet approved by the customer. 3. Both formal and development CM should uniquely identify managed information, control changes to this information through a structure of boards, provide status of all information either under control or released from CM, and conduct ongoing reviews and audits to ensure that the information under control is the same as that submitted. Eau2547.doc 48 4. The approval for a change to controlled information must be made by the highestlevel organization which last approved the information prior to placing it under CM. 5. CM should be implemented in a centralized library supported by an automated tool. 6. CM needs to be a continuous process implemented at the beginning of a program and continuing until product retirement. Implementation Guidelines 1. CM plans need to be developed by the ACQUIRER and the DEVELOPER to facilitate management control of information they own. The CM procedures of the ACQUIRER serve as the requirements for the CM plan that describes and documents how the DEVELOPER will implement a single CM process. This plan should control formal baselines and will include engineering information, reports, analysis information, test information, user information, and any other information approved for use or shared within the program. The CM process should include DEVELOPER-controlled and developed baselines as well as ACQUIRER-controlled baselines. It should also include release procedures for all classes of products under control, means for identification, change control procedures, status of products, and reviews and audits of information under CM control. The CM plan needs to be consistent with other plans and procedures used by the project. 2. The two types of baselines managed by CM are developmental and formal. Developmental baselines include all software, artifacts, documentation, tools, and other products not yet approved for delivery to the ACQUIRER but essential for successful production. Formal baselines are information/products (software, artifacts, or documentation) delivered and accepted by the ACQUIRER. Developmental baselines are owned by the DEVELOPER while formal baselines are owned by the ACQUIRER. 3. All information placed under CM as a result of meeting task exit criteria need to be uniquely identified by CM and placed under CM control. This includes software, artifacts, documents, commercial off-the-shelf (COTS), government off-the-shelf (GOTS), Eau2547.doc 49 operating systems, middleware, database management systems, database information, and any other information necessary to build, release, verify, and/or validate the product. 4. The CM process should be organizationally centered in a project library. This library will be the repository (current and historical) of all controlled products. The ACQUIRER and the DEVELOPER will implement an organizationally specific library. The library(s) will be partitioned according to the level of control of the information. 5. All information managed by CM is subject to change control. Change control consists of: a. b. c. d. Identification Reporting Analysis Implementation 6. The change control process needs to be implemented through an appropriate change mechanism tied to who owns the information: a. Change control boards, which manage formal baseline products. b. Interface boards, which manage jointly owned information c. Engineering review boards, which manage DEVELOPER-controlled information. 7. Any information released from the CM library should be described by a Version Description Document (Software Version Description under 498). The version description should consist of any inventory of all components by version identifier, an identification of open problems, closed problems, differences between versions, notes and assumptions, and build instructions. Additionally, each library partition should be described by a current version description that contains the same information. Return to Top 8. Manage and Trace Requirements Eau2547.doc 50 Practice Essentials 1. Before any design is initiated, requirements for that segment of the software need to be agreed to. 2. Requirements tracing should be a continuous process providing the means to trace from the user requirement to the lowest level software component. 3. Tracing shall exist not only to user requirements but also between products and the test cases used to verify their successful implementation. 4. All products that are used as part of the trace need to be under configuration control. 5. Requirements tracing should use a tool and be kept current as products are approved and placed under CM. 6. Requirements tracing should address system, hardware, and software and the process should be defined in the system engineering management plan and the software development plan. Implementation Guidelines 1. The program needs to define and implement a requirements management plan that addresses system, hardware, and software requirements. This plan should be linked to the SDP. 2. All requirements need to be documented, reviewed, and entered into a requirements management tool and put under CM. This requirements information should be kept current. 3. The CM plan should describe the process for keeping requirements data internally consistent and consistent with other project data. 4. Requirements traceability needs to be maintained through specification, design, code, and testing. Eau2547.doc 51 5. Requirements should be visible to all project participants. Return to Top 9. Use System-Based Software Design Practice Essentials 1. All methods used to define system architecture and software design should be documented in the system engineering management plan and software development plan and be frequently and regularly evaluated through audits conducted by an independent program organization. 2. Software engineering needs to participate in the definition of system architectures and should provide an acceptance gate before software requirements are defined. 3. The allocation of system architecture to hardware, software, or operational procedures needs to be the result of a predefined engineering process and be tracked through traceability and frequent quality evaluations. 4. All agreed to system architectures, software requirements, and software design decisions should be placed under CM control when they are approved for program implementation. 5. All architecture and design components need to be approved through an inspection prior to release to CM. This inspection should evaluate the process used to develop the product, the form and structure of the product, the technical integrity, and the adequacy to support future applications of the product to program needs. 6. All system architecture decisions should be based on a predefined engineering process and trade studies conducted to evaluate alternatives. Implementation Guidelines Eau2547.doc 52 1. The DEVELOPER should ensure that the system and software architectures are developed and maintained consistent with standards, methodologies, and external interfaces specified in the system and software development plans. 2. Software engineers need to be an integral part of the team performing systems engineering tasks that influence software. 3. Systems engineering requirements trade studies should include efforts to mitigate software risks. 4. System architecture specifications need to be maintained under CM. 5. The system and software architecture and architecture methods need to be consistent with each other. 6. System requirements, including derived requirements, need to be documented and allocated to hardware components and software components. 7. The requirements for each software component in the system architecture and derived requirements need to be allocated among all components and interfaces of the software component in the system architecture. Return to Top 10. Ensure Data and Database Interoperability Practice Essentials 1. All data and database implementation decisions should considerinteroperability issues and, as interoperability factors change, these decisions should be revisited. 2. Program standards should exist for database implementation and for the data elements that are included. These standards should include process standards for defining the database and entering information into it and product standards that define the structure, elements, and other essential database factors. Eau2547.doc 53 3. All data and databases should be structured in accordance with program requirements, such as the DII COE, to provide interoperability with other systems. 4. All databases shared with the program need to be under CM control and managed through the program change process. 5. Databases and data should be integrated across the program with data redundancy kept to a minimum. 6. When using multiple COTS packages, compatibility of the data/referential integrity mechanisms need to be considered to ensure consistency between databases. Implementation Guidelines 1. The DEVELOPER needs to ensure that data files and databases are developed with standards and methodologies. 2. The DEVELOPER needs to ensure that data entities and data elements are consistent with the DoD data model. 3. All data and databases should be structured in compliance with DII COE to provide interoperability with other systems. 4. Data integrity and referential integrity should be maintained automatically by COTS DBMSs or other COTS software packages. The DEVELOPER should avoid developing its package, if at all possible. Before selecting multiple COTS software packages, the DEVELOPER should study the compatibility of the data/referential integrity mechanisms of these COTS packages and obtain assurance from the COTS vendors first. 5. Unnecessary data redundancy should be reduced to minimum. 6. Data and databases should be integrated as much as possible. Except data for temporary use or for analysis/report purposes, each data item should be updated only once, and the changes should propagate automatically everywhere. Eau2547.doc 54 Return to Top 11. Define and Control Interfaces Practice Essentials 1. Before completion of system-level requirements, a complete inventory of all external interfaces needs to be completed. 2. All external interfaces need to be described as to source, format, structure, content, and method of support and this definition, or interface profile, needs to be placed under CM control. 3. Any changes to this interface profile should require concurrence by the interface owners prior to being made. 4. Internal software interfaces should be defined as part of the design process and managed through CM. 5. Interfaces should be inspected as part of the software inspection process. 6. Each software or system interface needs to be tested individually and a test of interface support should be conducted in a stressed and anomalous test environment. Implementation Guidelines 1. All internal and external interfaces need to be documented and maintained under CM control. 2. Changes to interfaces require concurrence by the interface owners prior to being made. 3. Milestones related to external interfaces should be tracked in the project activity network. [Keep these milestones off your critical path.] 4. Subsystem interfaces should be controlled at the program level. Eau2547.doc 55 Return to Top 12. Design Twice, Code Once Practice Essentials 1. All design processes should follow methods documented in the software development plan. 2. All designs need to be subject to verification of characteristics, which are included as part of the design standards for the product produced. 3. All designs should be evaluated through a structured inspection prior to release to CM. This inspection should consider reuse, performance, interoperability, security, safety, reliability, and limitations. 4. Traceability needs to be maintained through the design and verified as part of the inspection process. 5. Critical components should be evaluated through a specific white-box test level step. 6. Design can be incrementally specified when an incremental release or evolution life cycle model is used provided the CM process is adequate to support control of incremental designs and the inspection process is adapted to this requirement. Implementation Guidelines 1. When reuse of existing software is planned, the system and software architectures should be designed to facilitate this reuse. 2. When an incremental release life cycle model is planned, the system and software architectures need to be completed in the first release or, at most,extended in releases after the first without changes to the architecture of previous releases. 3. The system and software architectures will be verified using methods specified in the SDP. This verification will be conducted during a structured inspection of the software Eau2547.doc 56 architecture and will include corroboration that the architecture will support all reuse, performance, interoperability, security, safety, and reliability requirements. The architecture will be under CM. Return to Top 13. Assess Reuse Risks and Costs Practice Essentials 1. The use of reuse components, COTS, GOTS, or any other non-developmental items (NDI) should be treated as a risk and managed through risk management. 2. Application of reuse components, COTS, GOTS, or any other NDI will be made only after successful completion of a NDI acceptance inspection. This inspection needs to consider the process used to develop it, how it was document, number of users, user experience, and compliance with essential program considerations such as safety or security. 3. Before a decision is made to reuse a product or to acquire COTS, GOTS, or NDI, a complete cost trade-off should be made considering the full life cycle costs, update requirements, maintenance costs, warranty and licensing costs, and any other considerations which impact use of the product throughout its life cycle. 4. All reuse products, COTS, GOTS, or NDI decisions should be based on architectural and design definitions and be traceable back to an approved user requirement. 5. All reuse components, COTS, and COTS need to be tested individually first against program requirements and in an integrated software and system configuration prior to release for testing according to the program test plan. 6. Reuse, COTS, GOTS, and NDI decisions will be continuously revisited as program conditions change. Implementation Guidelines Eau2547.doc 57 1. The DEVELOPER will establish a reuse plan for the integration of COTS, GOTS, and in-house software. This plan needs to include discussion and allocation of whom and by what process reused software code is tested, verified, modified, and maintained. 2. The reuse plan should be in the SDP and document an approach for evaluating and enforcing reused functionality against system requirements. 3. The reuse plan should suggest a system engineering process that identifies software requirements by taking existing, reusable software components into account. 4. The test plan should identify the testing of the integrated reused code. 5. When integrating COTS, GOTS, and in-house software, ensure accurate cost estimation of integrating the reused code into the system. The cost of integrating unmodified reused code is approximately one-third the cost of developing code without reuse. 6. The DEVELOPER and the ACQUIRER need to be able to plan for the estimated costs of obtaining the necessary development and run-time licenses over the system's life cycle and the maintenance/support critical to the product, including source code availability. Return to Top PRODUCT STABILITY AND INTEGRITY 14. Inspect Requirements and Design Practice Essentials 1. All products that are placed under CM and are used as a basis for subsequent development need to be subjected to successful completion of a formal inspection prior to its release to CM. Eau2547.doc 58 2. The inspection needs to follow a rigorous process defined in the software development plan and should be based on agreed-to entry and exit criteria for that specific product. 3. At the inspection, specific metrics should be collected and tracked which will describe defects, defect removal efficiency, and efficiency of the inspection process. 4. All products to be placed under CM should be inspected as close to their production as feasible. 5. Inspections should be conducted beginning with concept definition and ending with completion of the engineering process. 6. The program needs to fund inspections and track rework savings. Implementation Guidelines 1. The DEVELOPER will implement a formal, structured inspection/peer review process that begins with the first system requirements products and continue through architecture, design, code, integration, testing, and documentation products and plans. The plan needs to be documented and controlled as per the SDP. 2. The project should set a goal of finding at least 80 percent of the defects in every product undergoing a structured peer review or other formal inspection. 3. Products should not be accepted into a CM baseline until they have satisfactorily completed a structured peer review. 4. The DEVELOPER needs to collect and report metrics concerning the number of defects found in each structured peer review, the time between creating and finding each defect, where and when the defect was identified, and the efficiency of defect removal. 5. Successful completion of inspections should act as the task exit criteria for non-Levelof-Effort earned value metrics (and other metrics used to capture effectiveness of the Eau2547.doc 59 formal inspection process) and as gates to place items under increasing levels of CM control. 6. The DEVELOPER should use a structured architecture inspection technique to verify correctness and related system performance characteristics. Return to Top 15. Manage Testing as a Continuous Process Practice Essentials 1. All testing should follow a preplanned process, which is agreed to and funded. 2. Every product that is placed under CM should be tested by a corresponding testing activity. 3. All tests should consider not only a nominal system condition but also address anomalous and recovery aspects of the system. 4. Prior to delivery, the system needs to be tested in a stressed environment, nominally in excess of 150 percent of its rated capacities. 5. All test products (test cases, data, tools, configuration, and criteria) should be released through CM and be documented in a software version description document. 6. Every test should be described in traceable procedures and have pass-fail criteria included. Implementation Guidelines 1. The testing process must be consistent with the RFP and the contract. The award fee should incentivize implementation of the testing practices described below. Eau2547.doc 60 2. The ACQUIRER and DEVELOPER need to plan their portion of the test process and document this plan with test cases and detailed test descriptions. These test cases should use cases based on projected operational mission scenarios. 3. The testing process should also include stress/load testing for stability purpose (i.e., at 95% CPU use, system stability is still guaranteed….) 4. The test plan should include a "justifiable testing stoppage criteria." This gives testers a goal. If your testing satisfies these criteria, then the product is ready for release. 5. The test process should thoroughly test the interfaces between any in-house and COTS functionality. These tests should include timing between COTS functionality and the bespoken functionality. The test plans need to pay serious attention to how to demonstrate that, if the COTS software fails, how to test that the rest of the software can recover adequately. This involves some very serious stress testing using fault injection testing. 6. Software testing should include a traceable white-box and other test process verifying implemented software against CM-controlled design documentation and the requirements traceability matrix. 7. A level of the white-box test coverage should be specified that is appropriate for the software being tested. 8. The white-box and other testing should use automated tools to instrument the software to measure test coverage. 9. All builds for white-box testing need to be done with source code obtained from the CM library. 10. Frequent builds require test automation, since more frequent compiles will force quick turnaround on all tests, especially during regression testing. However, this requires a high degree of test automation. Eau2547.doc 61 11. A black-box test of integration builds needs to include functional, interface, error recovery, stress, and out-of-bounds input testing. 12. Reused components and objects require high-level testing consistent with the operational/target environment. 13. Software testing includes a separate black-box test level to validate implemented software. All black-box software tests should trace to controlled requirements and be executed using software built from controlled CM libraries. 14. In addition to static requirements, a black-box test of the fully integrated system will be against scenarios-sequences of events designed to model field operation. 15. Performance testing for systems (e.g., performing 10,000 tests/second still yields response times under 2 seconds) should be tested as an integral part of the black-box test process. 16. An independent QA team should periodically audit selected test cases, test traceability, test execution, and test reports providing the results of this audit to the ACQUIRER. (The results of this or similar audits may be used as a factor in the calculation of Award Fee.) 17. Each test developed needs to include pass/fail criteria. Return to Top 16. Compile and Smoke Test Frequently Practice Essentials 1. All tests should use systems that are built on a frequent and regular basis (nominally no less than twice a week). 2. All new releases should be regression tested by CM prior to release to the test organization. Eau2547.doc 62 3. Smoke testing should qualify new capability or components only after successful regression test completion. 4. All smoke tests should be based on a pre-approved and traceable procedure and run by an independent organization (not the engineers who produced it). 5. All defects identified should be documented and be subject to the program change control process. 6. Smoke test results should be visible and provided to all project personnel. Implementation Guidelines 1. From the earliest opportunity to assess the progress of developed code, the DEVELOPER needs to use a process of frequent (one- to two-week intervals) software compile-builds as a means for finding software integration problems early. 2. It is required that a regression facility that incorporates a full functional test suite be applied with the build strategy. 3. Results of testing of each software build should be made available to all project personnel Clear and accurate definition of a project is one of the most important actions you can take to ensure the project's success. The clearer the target the more likely you are to hit it. Defining a project is a process of selection and reduction of the ideas and perspectives of those involved into a set of clearly defined objectives, key success criteria and evaluated risks. This definition process should culminate in the production of a Project Definition document, sometimes called a Project Charter. The Project Definition document should be approved and issued by a manager with the authority to apply organisational resources to the project activities. Therefore, the seniority of the manager or the management team will be commensurate with the size, cost and business value of the Eau2547.doc 63 project. As a minimum, the Project Definition should include a statement of the business need that the project seeks to address and the description of the product, service or deliverable business objectives that will be its output. When a project is performed under a contract between seller and buyer, the signed contract may well serve as the project charter for the seller. However this may not necessarily be the case for the buyer whose project may include more than the product or service purchase under the contract. The way to define a project is to ask a standard set of questions of yourself (as project leader) the project team, colleagues with particular expertise and senior managers. The questions fall into the categories given below. Attached are guideline formats for Report 1, Project Definition, and Report R2, Project Proposal. Your proposal will be regarded as a ``contract'', and you will be expected to perform as promised both by your company and by your faculty advisor. The Interim Report (R3) is a record of progress during the first term. This report must be self-contained, starting with a brief description of the problem and the company background. You should describe the data collected, preliminary analysis and conclusions, and plans for the next term. In Report R4, Alternatives, Tentative Results and Conclusions, you will list alternative approaches to the problem in sufficient detail so that your client can assess the different possibilities. The Final Report (R5) must be comprehensive and self-contained. A reader must be able to get a complete picture of the problem and what you have done over the two terms to solve the problem. Eau2547.doc 64 Project Definition Work Breakdown Structure: A hierarchical outline of an undertaking described in the project definition, the work breakdown structure (WBS) is the basis for the organization and coordination of a project. A WBS consists of a hierarchy of elements that form a logical structure for the categorization of project tasks and activities. They are often used for cost control and invoicing purposes. To fully utilize this functionality, the following products should be evaluated  External Project Systems  SAP R/3 Enterprise / mySAP ERP / mySAP Product Lifecycle Management Project Activity Network: An activity network contains information about the activities that must be performed to complete a project. These activities can be linked in a network for the purpose of creating the project schedule and for critical path planning. To fully utilize this functionality, the following products should be evaluated  SAP R/3 Enterprise / mySAP ERP / mySAP Product Lifecycle Management Eau2547.doc 65 Integrated Material & Resource Planning: The activities in a project require resources including money, materials, and labor. This information is directly related to the activity network and work breakdown structure (WBS) allowing an integrated view of the planning requirements for a contract or project. To fully utilize this functionality, the following products should be evaluated  SAP R/3 Enterprise / mySAP ERP / mySAP Product Lifecycle Management  SAP R/3 Enterprise / mySAP ERP / mySAP Supply Chain Management Collaborative Project Management: Collaborative projects require the exchange of project management data over the Internet. This would include the project basic data of WBS and Activity network and also objects such as documents that are linked to those elements. To fully utilize this functionality, the following products should be evaluated  SAP R/3 Enterprise / mySAP ERP / mySAP Product Lifecycle Management Eau2547.doc

CMM กับ การพัฒนาซอฟต์แวร์(ต่อ)

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib