เทคนิคการประมาณราคา - คู่มือฉบับย่อ

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

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

• ข้อมูลในอดีต / ประสบการณ์ในอดีต
• เอกสาร / ความรู้ที่มีอยู่
• Assumptions
• ระบุความเสี่ยง

ขั้นตอนพื้นฐานสี่ขั้นตอนในการประมาณโครงการซอฟต์แวร์ ได้แก่ -

• ประมาณขนาดของผลิตภัณฑ์ที่พัฒนา
• ประเมินความพยายามเป็นรายเดือนหรือคน - ชั่วโมง
• ประมาณการกำหนดการเป็นเดือนปฏิทิน
• ประเมินต้นทุนโครงการในสกุลเงินที่ตกลงกัน

ข้อสังเกตเกี่ยวกับการประมาณค่า

• การประมาณค่าไม่จำเป็นต้องเป็นงานครั้งเดียวในโครงการ สามารถเกิดขึ้นในระหว่าง -

  • การได้รับโครงการ
  • การวางแผนโครงการ
  • การดำเนินโครงการตามความต้องการที่เกิดขึ้น

• ต้องเข้าใจขอบเขตของโครงการก่อนที่กระบวนการประมาณจะเริ่มขึ้น การมีข้อมูลโครงการในอดีตจะเป็นประโยชน์

• เมตริกโครงการสามารถให้มุมมองทางประวัติศาสตร์และข้อมูลที่มีคุณค่าสำหรับการสร้างประมาณการเชิงปริมาณ

• การวางแผนต้องการผู้จัดการด้านเทคนิคและทีมซอฟต์แวร์เพื่อให้คำมั่นสัญญาเบื้องต้นเนื่องจากจะนำไปสู่ความรับผิดชอบและความรับผิดชอบ

• ประสบการณ์ที่ผ่านมาสามารถช่วยได้มาก

• ใช้เทคนิคการประมาณอย่างน้อยสองอย่างเพื่อให้ได้ค่าประมาณและกระทบยอดค่าผลลัพธ์ ดูเทคนิคการสลายตัวในส่วนถัดไปเพื่อเรียนรู้เกี่ยวกับการกระทบยอดค่าประมาณ

• แผนควรทำซ้ำและอนุญาตให้มีการปรับเปลี่ยนเมื่อเวลาผ่านไปและทราบรายละเอียดเพิ่มเติม

แนวทางการประมาณโครงการทั่วไป

แนวทางการประมาณโครงการที่ใช้กันอย่างแพร่หลายคือ Decomposition Technique. เทคนิคการสลายตัวใช้วิธีแบ่งแยกและพิชิต การประมาณขนาดความพยายามและต้นทุนจะดำเนินการในลักษณะที่เป็นขั้นตอนโดยการแบ่งโครงการออกเป็นหน้าที่หลัก ๆ หรือกิจกรรมวิศวกรรมซอฟต์แวร์ที่เกี่ยวข้อง

Step 1 - ทำความเข้าใจขอบเขตของซอฟต์แวร์ที่จะสร้าง

Step 2 - สร้างขนาดซอฟต์แวร์โดยประมาณ

• เริ่มต้นด้วยคำชี้แจงขอบเขต

• แยกย่อยซอฟต์แวร์ออกเป็นฟังก์ชันที่สามารถประมาณค่าได้ทีละรายการ

• คำนวณขนาดของแต่ละฟังก์ชัน

• หาค่าความพยายามและค่าใช้จ่ายโดยประมาณโดยใช้ค่าขนาดกับเมตริกผลผลิตพื้นฐานของคุณ

• รวมค่าประมาณฟังก์ชันเพื่อสร้างค่าประมาณโดยรวมสำหรับทั้งโครงการ

Step 3- สร้างประมาณการของความพยายามและค่าใช้จ่าย คุณสามารถบรรลุความพยายามและการประมาณค่าใช้จ่ายได้โดยการแบ่งโครงการออกเป็นกิจกรรมด้านวิศวกรรมซอฟต์แวร์ที่เกี่ยวข้อง

• ระบุลำดับของกิจกรรมที่ต้องดำเนินการเพื่อให้โครงการเสร็จสมบูรณ์

• แบ่งกิจกรรมออกเป็นงานที่สามารถวัดผลได้

• ประเมินความพยายาม (เป็นชั่วโมง / วัน) ที่ต้องใช้ในการทำงานแต่ละอย่างให้เสร็จ

• รวมการประมาณการความพยายามของงานของกิจกรรมเพื่อสร้างค่าประมาณสำหรับกิจกรรม

• รับหน่วยต้นทุน (เช่นต้นทุน / หน่วยความพยายาม) สำหรับแต่ละกิจกรรมจากฐานข้อมูล

• คำนวณความพยายามและต้นทุนทั้งหมดสำหรับแต่ละกิจกรรม

• รวมความพยายามและการประมาณค่าใช้จ่ายสำหรับแต่ละกิจกรรมเพื่อสร้างความพยายามโดยรวมและประมาณการต้นทุนสำหรับทั้งโครงการ

Step 4- กระทบยอดประมาณการ: เปรียบเทียบค่าผลลัพธ์จากขั้นตอนที่ 3 กับค่าที่ได้รับจากขั้นตอนที่ 2 หากค่าประมาณทั้งสองชุดเห็นด้วยกันแสดงว่าตัวเลขของคุณมีความน่าเชื่อถือสูง มิฉะนั้นหากมีการประมาณการที่แตกต่างกันอย่างกว้างขวางให้ดำเนินการตรวจสอบเพิ่มเติมว่า -

• ขอบเขตของโครงการไม่ได้รับความเข้าใจอย่างเพียงพอหรือมีการตีความผิดพลาด

• ฟังก์ชันและ / หรือรายละเอียดของกิจกรรมไม่ถูกต้อง

• ข้อมูลในอดีตที่ใช้สำหรับเทคนิคการประมาณไม่เหมาะสมสำหรับการใช้งานหรือล้าสมัยหรือถูกนำไปใช้ในทางที่ผิด

Step 5 - ตรวจสอบสาเหตุของความแตกต่างแล้วกระทบยอดประมาณการ

ความแม่นยำในการประมาณการ

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

ปัจจัยสำคัญที่ส่งผลต่อความแม่นยำของการประมาณการ ได้แก่ -

• ความถูกต้องของข้อมูลอินพุตโดยประมาณทั้งหมด

• ความถูกต้องของการคำนวณโดยประมาณ

• ข้อมูลในอดีตหรือข้อมูลอุตสาหกรรมที่ใช้ในการปรับเทียบแบบจำลองนั้นตรงกับโครงการที่คุณกำลังประเมินมากน้อยเพียงใด

• ความสามารถในการคาดเดาของกระบวนการพัฒนาซอฟต์แวร์ขององค์กรของคุณ

• ความเสถียรของทั้งข้อกำหนดของผลิตภัณฑ์และสภาพแวดล้อมที่สนับสนุนความพยายามด้านวิศวกรรมซอฟต์แวร์

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

ต่อไปนี้เป็นแนวทางบางประการในการบรรลุค่าประมาณที่เชื่อถือได้

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

อ้างถึงส่วนแนวทางการประมาณการในบทนี้

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

ปัญหาการประมาณการ

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

ในขณะที่ประมาณการอาจมีการตั้งสมมติฐานบางประการ สิ่งสำคัญคือต้องสังเกตสมมติฐานเหล่านี้ทั้งหมดในใบประมาณการเนื่องจากบางส่วนยังไม่ได้บันทึกข้อสมมติฐานไว้ในใบประมาณการ

แม้แต่การประมาณการที่ดีก็ยังมีสมมติฐานความเสี่ยงและความไม่แน่นอนโดยธรรมชาติ แต่ก็มักจะถูกปฏิบัติราวกับว่ามีความถูกต้อง

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

• คุณยังสามารถรวมค่าความไม่แน่นอนเป็นค่าความน่าจะเป็นประกอบ ตัวอย่างเช่นมีความเป็นไปได้ 90% ที่โครงการจะเสร็จสมบูรณ์ในหรือก่อนวันที่กำหนด

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

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

• ตกลงกับไคลเอ็นต์ในการจัดการขอบเขตครีปเพื่อหลีกเลี่ยงการโอเวอร์รันกำหนดการ

• ความล้มเหลวในการรองรับสถานการณ์ฉุกเฉินในการประมาณการขั้นสุดท้ายทำให้เกิดปัญหา เช่นการประชุมกิจกรรมขององค์กร

• การใช้ทรัพยากรควรถือว่าน้อยกว่า 80% เนื่องจากทรัพยากรจะมีประสิทธิผลเพียง 80% ของเวลาของพวกเขา หากคุณกำหนดทรัพยากรที่มีการใช้งานมากกว่า 80% จะมีความคลาดเคลื่อน

แนวทางการประมาณการ

เราควรคำนึงถึงแนวทางต่อไปนี้ในขณะที่ประเมินโครงการ -

• ถามประสบการณ์ของคนอื่นในระหว่างการประมาณค่า นอกจากนี้ให้ใส่ประสบการณ์ของคุณเองในงาน

• สมมติว่าทรัพยากรจะมีประสิทธิผลเพียง 80 เปอร์เซ็นต์ของเวลา ดังนั้นในระหว่างการประมาณค่าใช้ทรัพยากรน้อยกว่า 80%

• ทรัพยากรที่ทำงานในหลายโครงการใช้เวลานานกว่าในการทำงานให้เสร็จเนื่องจากเวลาที่เสียไปในการสลับระหว่างโครงการเหล่านี้

• รวมเวลาการจัดการในการประมาณใด ๆ

• สร้างสถานการณ์ฉุกเฉินสำหรับการแก้ปัญหาการประชุมและเหตุการณ์ที่ไม่คาดคิดอื่น ๆ เสมอ

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

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

• ใช้ค่าประมาณที่อิงตามนักพัฒนาเนื่องจากค่าประมาณที่จัดทำโดยบุคคลอื่นที่ไม่ใช่ผู้ที่จะทำงานจะมีความแม่นยำน้อยกว่า

• ใช้คนหลายคนในการประมาณและใช้เทคนิคการประมาณค่าต่างๆ

• กระทบยอดประมาณการ สังเกตการบรรจบกันหรือการแพร่กระจายระหว่างการประมาณการ การบรรจบกันหมายความว่าคุณมีค่าประมาณที่ดี เทคนิค Wideband-Delphi สามารถใช้เพื่อรวบรวมและอภิปรายการประมาณการโดยใช้กลุ่มคนโดยมีจุดประสงค์เพื่อสร้างการประมาณที่ถูกต้องและเป็นกลาง

• ประเมินโครงการใหม่หลายครั้งตลอดวงจรชีวิต

ก Function Point(FP) เป็นหน่วยของการวัดเพื่อแสดงจำนวนฟังก์ชันการทำงานทางธุรกิจระบบข้อมูล (เป็นผลิตภัณฑ์) ให้กับผู้ใช้ FPs วัดขนาดซอฟต์แวร์ พวกเขาได้รับการยอมรับอย่างกว้างขวางว่าเป็นมาตรฐานอุตสาหกรรมสำหรับการปรับขนาดตามหน้าที่

สำหรับการปรับขนาดซอฟต์แวร์ตาม FP จะมีการกำหนดมาตรฐานและ / หรือข้อกำหนดสาธารณะที่เป็นที่ยอมรับหลายประการ ในปี 2013 เหล่านี้คือ -

มาตรฐาน ISO

• COSMIC- ISO / IEC 19761: 2011 วิศวกรรมซอฟต์แวร์ วิธีการวัดขนาดที่ใช้งานได้

• FiSMA - ISO / IEC 29881: 2008 เทคโนโลยีสารสนเทศ - วิศวกรรมซอฟต์แวร์และระบบ - วิธีการวัดขนาดการทำงานของ FiSMA 1.1

• IFPUG - ISO / IEC 20926: 2009 วิศวกรรมซอฟต์แวร์และระบบ - การวัดซอฟต์แวร์ - วิธีการวัดขนาดการทำงานของ IFPUG

• Mark-II - ISO / IEC 20968: 2002 วิศวกรรมซอฟต์แวร์ - การวิเคราะห์จุดฟังก์ชัน Ml II - คู่มือแนวทางปฏิบัติในการนับ

• NESMA - ISO / IEC 24570: 2005 วิศวกรรมซอฟต์แวร์ - วิธีการวัดขนาดฟังก์ชัน NESMA เวอร์ชัน 2.1 - คำจำกัดความและแนวทางการนับสำหรับการประยุกต์ใช้การวิเคราะห์จุดฟังก์ชัน

ข้อกำหนดกลุ่มการจัดการออบเจ็กต์สำหรับจุดฟังก์ชันอัตโนมัติ

Object Management Group (OMG) ซึ่งเป็นสมาคมมาตรฐานอุตสาหกรรมคอมพิวเตอร์แบบเปิดและไม่แสวงหาผลกำไรได้นำข้อกำหนด Automated Function Point (AFP) ที่นำโดย Consortium for IT Software Quality เป็นมาตรฐานสำหรับการนับ FP โดยอัตโนมัติตามแนวทางของ International Function Point User Group (IFPUG)

Function Point Analysis (FPA) techniqueระบุจำนวนฟังก์ชันที่มีอยู่ภายในซอฟต์แวร์ในรูปแบบที่มีความหมายต่อผู้ใช้ซอฟต์แวร์ FPs พิจารณาจำนวนฟังก์ชันที่พัฒนาตามข้อกำหนดข้อกำหนด

Function Points (FP) Countingอยู่ภายใต้ชุดกฎเกณฑ์กระบวนการและแนวทางมาตรฐานที่กำหนดโดย International Function Point Users Group (IFPUG) มีการเผยแพร่ในคู่มือแนวทางปฏิบัติในการนับ (CPM)

ประวัติการวิเคราะห์จุดฟังก์ชัน

แนวคิดของ Function Points ถูกนำมาใช้โดย Alan Albrecht จาก IBM ในปี 1979 ในปี 1984 Albrecht ได้ปรับแต่งวิธีการ คำแนะนำเกี่ยวกับฟังก์ชันพอยต์ฉบับแรกได้รับการตีพิมพ์ในปี พ.ศ. 2527 International Function Point Users Group (IFPUG) เป็นองค์กรผู้ใช้ซอฟต์แวร์เมตริก Function Point Analysis ในสหรัฐอเมริกา International Function Point Users Group (IFPUG)เป็นองค์กรที่อยู่ภายใต้การกำกับดูแลของสมาชิกที่ไม่แสวงหาผลกำไรซึ่งก่อตั้งขึ้นในปี 1986 IFPUG เป็นเจ้าของ Function Point Analysis (FPA) ตามที่กำหนดไว้ในมาตรฐาน ISO 20296: 2009 ซึ่งระบุคำจำกัดความกฎและขั้นตอนในการใช้วิธีการวัดขนาดการทำงาน (FSM) ของ IFPUG IFPUG เก็บรักษาคู่มือแนวทางปฏิบัติในการนับคะแนนฟังก์ชัน (CPM) CPM 2.0 เปิดตัวในปี 1987 และตั้งแต่นั้นมาก็มีการทำซ้ำหลายครั้ง CPM รุ่น 4.3 อยู่ในปี 2010

CPM รุ่น 4.3.1 พร้อมการแก้ไข ISO ที่รวมไว้คือในปี 2010 มาตรฐาน ISO (IFPUG FSM) - การวัดขนาดการทำงานซึ่งเป็นส่วนหนึ่งของ CPM 4.3.1 เป็นเทคนิคในการวัดซอฟต์แวร์ในแง่ของฟังก์ชันการทำงานที่มีให้ CPM เป็นมาตรฐานที่ได้รับการรับรองในระดับสากลภายใต้ ISO / IEC 14143-1 เทคโนโลยีสารสนเทศ - การวัดซอฟต์แวร์

กระบวนการเบื้องต้น (EP)

Elementary Process เป็นหน่วยที่เล็กที่สุดของความต้องการของผู้ใช้ที่ใช้งานได้ซึ่ง -

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

ฟังก์ชั่น

มีฟังก์ชันสองประเภท -

• ฟังก์ชั่นข้อมูล
• ฟังก์ชั่นการทำธุรกรรม

ฟังก์ชั่นข้อมูล

ฟังก์ชันข้อมูลมีสองประเภท -

• ไฟล์ลอจิคัลภายใน
• ไฟล์อินเทอร์เฟซภายนอก

ฟังก์ชันข้อมูลประกอบด้วยทรัพยากรภายในและภายนอกที่มีผลต่อระบบ

Internal Logical Files

Internal Logical File (ILF) คือกลุ่มข้อมูลที่เกี่ยวข้องกับตรรกะหรือข้อมูลการควบคุมที่สามารถระบุตัวตนได้ซึ่งอยู่ภายในขอบเขตของแอปพลิเคชัน วัตถุประสงค์หลักของ ILF คือการเก็บรักษาข้อมูลผ่านกระบวนการพื้นฐานอย่างน้อยหนึ่งกระบวนการของแอปพลิเคชันที่ถูกนับ ILF มีความหมายโดยธรรมชาติที่ได้รับการบำรุงรักษาภายในมีโครงสร้างเชิงตรรกะและถูกเก็บไว้ในไฟล์ (ดูรูปที่ 1)

External Interface Files

ไฟล์อินเทอร์เฟซภายนอก (EIF) คือกลุ่มข้อมูลที่เกี่ยวข้องกับตรรกะหรือข้อมูลควบคุมที่สามารถระบุตัวตนได้ซึ่งแอปพลิเคชันใช้เพื่อวัตถุประสงค์ในการอ้างอิงเท่านั้น ข้อมูลอยู่นอกขอบเขตของแอปพลิเคชันทั้งหมดและได้รับการดูแลใน ILF โดยแอปพลิเคชันอื่น EIF มีความหมายโดยธรรมชาติว่าได้รับการดูแลจากภายนอกต้องมีการพัฒนาอินเทอร์เฟซเพื่อรับข้อมูลจากไฟล์ (ดูรูปที่ 1)

ฟังก์ชั่นการทำธุรกรรม

มีฟังก์ชันธุรกรรมสามประเภท

• อินพุตภายนอก
• เอาต์พุตภายนอก
• คำถามภายนอก

ฟังก์ชันธุรกรรมประกอบด้วยกระบวนการที่แลกเปลี่ยนระหว่างผู้ใช้แอปพลิเคชันภายนอกและแอปพลิเคชันที่กำลังวัด

External Inputs

อินพุตภายนอก (EI) เป็นฟังก์ชันการทำธุรกรรมที่ข้อมูลจะ "เข้า" แอปพลิเคชันจากภายนอกขอบเขตสู่ภายใน ข้อมูลนี้มาจากภายนอกแอปพลิเคชัน

• ข้อมูลอาจมาจากหน้าจอป้อนข้อมูลหรือแอปพลิเคชันอื่น
• EI คือวิธีที่แอปพลิเคชันรับข้อมูล
• ข้อมูลอาจเป็นได้ทั้งข้อมูลควบคุมหรือข้อมูลทางธุรกิจ
• ข้อมูลอาจถูกใช้เพื่อรักษาไฟล์ Logical ภายในอย่างน้อยหนึ่งไฟล์
• หากข้อมูลเป็นข้อมูลการควบคุมก็ไม่จำเป็นต้องอัพเดตไฟล์โลจิคัลภายใน (ดูรูปที่ 1)

External Outputs

External Output (EO) คือฟังก์ชั่นการทำธุรกรรมที่ข้อมูล "ออกมา" จากระบบ นอกจากนี้ EO อาจอัปเดต ILF ข้อมูลจะสร้างรายงานหรือไฟล์เอาต์พุตที่ส่งไปยังแอปพลิเคชันอื่น (ดูรูปที่ 1)

External Inquiries

External Inquiry (EQ) เป็นฟังก์ชันการทำธุรกรรมที่มีส่วนประกอบทั้งอินพุตและเอาต์พุตซึ่งส่งผลให้มีการดึงข้อมูล (ดูรูปที่ 1)

คำจำกัดความของ RETs, DETs, FTRs

ประเภทองค์ประกอบบันทึก

ประเภทองค์ประกอบระเบียน (RET) เป็นกลุ่มย่อยขององค์ประกอบที่สามารถระบุตัวตนของผู้ใช้ที่ใหญ่ที่สุดภายใน ILF หรือ EIF ที่ดีที่สุดคือดูการจัดกลุ่มข้อมูลเชิงตรรกะเพื่อช่วยในการระบุ

ประเภทองค์ประกอบข้อมูล

ประเภทองค์ประกอบข้อมูล (DET) คือกลุ่มย่อยข้อมูลภายใน FTR มีลักษณะเฉพาะและสามารถระบุตัวตนของผู้ใช้ได้

ประเภทไฟล์อ้างอิง

File Type Referenced (FTR) เป็นกลุ่มย่อยที่สามารถระบุตัวตนของผู้ใช้ที่ใหญ่ที่สุดภายใน EI, EO หรือ EQ ที่อ้างถึง

ฟังก์ชันธุรกรรม EI, EO, EQ ถูกวัดโดยการนับ FTR และ DET ที่ประกอบด้วยกฎการนับตาม ในทำนองเดียวกันฟังก์ชันข้อมูล ILF และ EIF จะถูกวัดโดยการนับ DET ​​และ RET ที่ประกอบด้วยกฎการนับตาม การวัดฟังก์ชันธุรกรรมและฟังก์ชันข้อมูลจะใช้ในการนับ FP ซึ่งส่งผลให้มีขนาดหน้าที่หรือจุดของฟังก์ชัน

กระบวนการนับ FP ประกอบด้วยขั้นตอนต่อไปนี้ -

• Step 1 - กำหนดประเภทของการนับ

• Step 2 - กำหนดขอบเขตของการนับ

• Step 3 - ระบุแต่ละกระบวนการเบื้องต้น (EP) ที่ผู้ใช้ต้องการ

• Step 4 - กำหนด EP ที่ไม่ซ้ำกัน

• Step 5 - ฟังก์ชั่นการวัดข้อมูล

• Step 6 - วัดฟังก์ชันการทำธุรกรรม

• Step 7 - คำนวณขนาดการทำงาน (จำนวนจุดฟังก์ชันที่ไม่ได้ปรับ)

• Step 8 - กำหนด Value Adjustment Factor (VAF)

• Step 9 - คำนวณจำนวนจุดฟังก์ชันที่ปรับแล้ว

Note- General System Characteristics (GSCs) เป็นทางเลือกใน CPM 4.3.1 และย้ายไปที่ภาคผนวก ดังนั้นขั้นตอนที่ 8 และขั้นตอนที่ 9 สามารถข้ามไปได้

ขั้นตอนที่ 1: กำหนดประเภทของการนับ

การนับคะแนนฟังก์ชันมีสามประเภท -

• การนับคะแนนฟังก์ชันการพัฒนา
• การนับคะแนนฟังก์ชันแอปพลิเคชัน
• การนับคะแนนฟังก์ชันการเพิ่มประสิทธิภาพ

การนับคะแนนฟังก์ชันการพัฒนา

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

การนับคะแนนฟังก์ชันแอปพลิเคชัน

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

การนับคะแนนฟังก์ชันการเพิ่มประสิทธิภาพ

เมื่อมีการเปลี่ยนแปลงซอฟต์แวร์หลังการผลิตจะถือว่าเป็นการปรับปรุง ในการปรับขนาดโปรเจ็กต์การปรับปรุงดังกล่าวจำนวนจุดของฟังก์ชันจะถูกเพิ่มเปลี่ยนแปลงหรือลบในแอปพลิเคชัน

ขั้นตอนที่ 2: กำหนดขอบเขตของการนับ

ขอบเขตระบุเส้นขอบระหว่างแอปพลิเคชันที่กำลังวัดกับแอปพลิเคชันภายนอกหรือโดเมนผู้ใช้ (ดูรูปที่ 1)

เพื่อกำหนดขอบเขตทำความเข้าใจ -

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

ขั้นตอนที่ 3: ระบุแต่ละกระบวนการพื้นฐานที่ผู้ใช้ต้องการ

เขียนและ / หรือแยกย่อยความต้องการของผู้ใช้ที่ใช้งานได้เป็นหน่วยกิจกรรมที่เล็กที่สุดซึ่งเป็นไปตามเกณฑ์ทั้งหมดต่อไปนี้ -

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

ตัวอย่างเช่นความต้องการของผู้ใช้ตามหน้าที่ -“ รักษาข้อมูลพนักงาน” สามารถแยกย่อยออกเป็นกิจกรรมเล็ก ๆ เช่นเพิ่มพนักงานเปลี่ยนพนักงานลบพนักงานและสอบถามเกี่ยวกับพนักงาน

กิจกรรมแต่ละหน่วยที่ระบุจึงเป็นกระบวนการเบื้องต้น (EP)

ขั้นตอนที่ 4: กำหนดกระบวนการพื้นฐานเฉพาะ

เปรียบเทียบสอง EP ที่ระบุไว้แล้วให้นับเป็น EP เดียว (EP เดียวกัน) หาก -

• ต้องการ DET ชุดเดียวกัน
• ต้องการ FTR ชุดเดียวกัน
• ต้องการตรรกะการประมวลผลชุดเดียวกันเพื่อทำ EP

อย่าแยก EP ที่มีตรรกะการประมวลผลหลายรูปแบบออกเป็นหลาย Eps

ตัวอย่างเช่นหากคุณระบุว่า 'เพิ่มพนักงาน' เป็น EP ไม่ควรแบ่งออกเป็นสอง EP เพื่อพิจารณาข้อเท็จจริงที่ว่าพนักงานอาจมีหรือไม่มีผู้อยู่ในอุปการะ EP ยังคงเป็น 'เพิ่มพนักงาน' และมีการเปลี่ยนแปลงในตรรกะการประมวลผลและ DET ที่ต้องพิจารณาสำหรับผู้อยู่ในอุปการะ

ขั้นตอนที่ 5: วัดฟังก์ชันข้อมูล

จำแนกแต่ละฟังก์ชันข้อมูลเป็น ILF หรือ EIF

ฟังก์ชันข้อมูลจะถูกจัดประเภทเป็น -

• ไฟล์ลอจิคัลภายใน (ILF) หากได้รับการดูแลโดยแอปพลิเคชันที่กำลังวัด

• ไฟล์อินเทอร์เฟซภายนอก (EIF) หากมีการอ้างอิง แต่ไม่ได้รับการดูแลโดยแอปพลิเคชันที่กำลังวัด

ILF และ EIF สามารถมีข้อมูลทางธุรกิจข้อมูลควบคุมและข้อมูลตามกฎ ตัวอย่างเช่นการสลับโทรศัพท์ประกอบด้วยทั้งสามประเภท ได้แก่ ข้อมูลธุรกิจข้อมูลกฎและข้อมูลควบคุม ข้อมูลธุรกิจคือการโทรจริง ข้อมูลกฎคือวิธีที่ควรกำหนดเส้นทางการโทรผ่านเครือข่ายและข้อมูลการควบคุมคือวิธีที่สวิตช์สื่อสารระหว่างกัน

พิจารณาเอกสารประกอบการนับ ILF และ EIF ต่อไปนี้ -

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

ขั้นตอนที่ 5.1: นับ DET ​​สำหรับแต่ละฟังก์ชันข้อมูล

ใช้กฎต่อไปนี้เพื่อนับ DET ​​สำหรับ ILF / EIF -

• นับ DET ​​สำหรับฟิลด์ที่ระบุตัวตนของผู้ใช้แต่ละรายที่ไม่ซ้ำกันซึ่งเก็บรักษาไว้ในหรือดึงมาจาก ILF หรือ EIF ผ่านการดำเนินการของ EP

• นับเฉพาะ DET ที่ถูกใช้โดยแอปพลิเคชันที่วัดเมื่อสองแอปพลิเคชันขึ้นไปรักษาและ / หรืออ้างอิงฟังก์ชันข้อมูลเดียวกัน

• นับ DET ​​สำหรับแต่ละแอตทริบิวต์ที่ผู้ใช้ต้องการเพื่อสร้างความสัมพันธ์กับ ILF หรือ EIF อื่น

• ตรวจสอบแอตทริบิวต์ที่เกี่ยวข้องเพื่อตรวจสอบว่ามีการจัดกลุ่มและนับเป็น DET เดียวหรือไม่หรือนับเป็น DET หลายรายการ การจัดกลุ่มจะขึ้นอยู่กับว่า EP ใช้แอตทริบิวต์ภายในแอปพลิเคชันอย่างไร

ขั้นตอนที่ 5.2: นับ RET สำหรับแต่ละฟังก์ชันข้อมูล

ใช้กฎต่อไปนี้เพื่อนับ RET สำหรับ ILF / EIF -

• นับหนึ่ง RET สำหรับแต่ละฟังก์ชันข้อมูล
• นับหนึ่ง RET เพิ่มเติมสำหรับแต่ละกลุ่มย่อยเชิงตรรกะเพิ่มเติมของ DET ต่อไปนี้
  • เอนทิตีที่เกี่ยวข้องกับแอตทริบิวต์ที่ไม่ใช่คีย์
  • ประเภทย่อย (นอกเหนือจากประเภทย่อยแรก)
  • Attributive entity ในความสัมพันธ์อื่นที่ไม่ใช่บังคับ 1: 1

ขั้นตอนที่ 5.3: กำหนดความซับซ้อนของฟังก์ชันสำหรับแต่ละฟังก์ชันข้อมูล

ผลตอบแทน	ประเภทองค์ประกอบข้อมูล (DET)
	1-19	20-50	>50
1	ล	ล	ก
2 ถึง 5	ล	ก	ซ
> 5	ก	ซ	ซ

ความซับซ้อนในการทำงาน: L = ต่ำ; A = ค่าเฉลี่ย; H = สูง

ขั้นตอนที่ 5.4: วัดขนาดการทำงานสำหรับแต่ละฟังก์ชันข้อมูล

ความซับซ้อนในการทำงาน	FP Count สำหรับ ILF	FP Count สำหรับ EIF
ต่ำ	7	5
เฉลี่ย	10	7
สูง	15	10

ขั้นตอนที่ 6: วัดฟังก์ชันการทำธุรกรรม

ในการวัดฟังก์ชันการทำธุรกรรมต่อไปนี้เป็นขั้นตอนที่จำเป็น -

ขั้นตอนที่ 6.1: จำแนกแต่ละฟังก์ชันการทำธุรกรรม

ฟังก์ชันการทำธุรกรรมควรจัดประเภทเป็นอินพุตภายนอกเอาต์พุตภายนอกหรือการสอบถามจากภายนอก

อินพุตภายนอก

อินพุตภายนอก (EI) เป็นกระบวนการพื้นฐานที่ประมวลผลข้อมูลหรือควบคุมข้อมูลที่มาจากนอกขอบเขต วัตถุประสงค์หลักของ EI คือการรักษา ILF หนึ่งรายการขึ้นไปและ / หรือเพื่อปรับเปลี่ยนพฤติกรรมของระบบ

ต้องใช้กฎต่อไปนี้ทั้งหมด -

• ข้อมูลหรือข้อมูลควบคุมได้รับจากภายนอกขอบเขตของแอปพลิเคชัน

• มีการเก็บรักษา ILF อย่างน้อยหนึ่งรายการหากข้อมูลที่เข้าสู่ขอบเขตไม่ได้ควบคุมข้อมูลที่เปลี่ยนแปลงพฤติกรรมของระบบ

• สำหรับ EP ที่ระบุต้องใช้หนึ่งในสามคำสั่ง -

  • ตรรกะการประมวลผลไม่เหมือนใครจากตรรกะการประมวลผลที่ดำเนินการโดย EI อื่นสำหรับแอปพลิเคชัน

  • ชุดองค์ประกอบข้อมูลที่ระบุแตกต่างจากชุดที่ระบุสำหรับ EI อื่นในแอปพลิเคชัน

  • ILF หรือ EIF ที่อ้างถึงแตกต่างจากไฟล์ที่อ้างอิงโดย EI อื่นในแอปพลิเคชัน

เอาต์พุตภายนอก

External Output (EO) เป็นกระบวนการพื้นฐานที่ส่งข้อมูลหรือควบคุมข้อมูลนอกขอบเขตของแอปพลิเคชัน EO รวมถึงการประมวลผลเพิ่มเติมนอกเหนือจากการสอบถามจากภายนอก

วัตถุประสงค์หลักของ EO คือการนำเสนอข้อมูลให้กับผู้ใช้ผ่านตรรกะการประมวลผลนอกเหนือจากหรือนอกเหนือจากการดึงข้อมูลหรือข้อมูลการควบคุม

ตรรกะการประมวลผลต้อง -

• มีสูตรทางคณิตศาสตร์หรือการคำนวณอย่างน้อยหนึ่งสูตร
• สร้างข้อมูลที่ได้รับ
• รักษา ILF หนึ่งรายการขึ้นไป
• ปรับเปลี่ยนพฤติกรรมของระบบ

ต้องใช้กฎต่อไปนี้ทั้งหมด -

• ส่งข้อมูลหรือควบคุมข้อมูลภายนอกขอบเขตของแอปพลิเคชัน
• สำหรับ EP ที่ระบุต้องใช้หนึ่งในสามคำสั่ง -
  • ตรรกะการประมวลผลไม่เหมือนใครจากตรรกะการประมวลผลที่ดำเนินการโดย EO อื่นสำหรับแอปพลิเคชัน
  • ชุดองค์ประกอบข้อมูลที่ระบุแตกต่างจาก EO อื่น ๆ ในแอปพลิเคชัน
  • ILF หรือ EIF ที่อ้างถึงแตกต่างจากไฟล์ที่อ้างถึงโดย EO อื่นในแอปพลิเคชัน

นอกจากนี้ต้องใช้กฎข้อใดข้อหนึ่งต่อไปนี้ -

• ตรรกะการประมวลผลประกอบด้วยสูตรทางคณิตศาสตร์หรือการคำนวณอย่างน้อยหนึ่งรายการ
• ตรรกะการประมวลผลรักษา ILF อย่างน้อยหนึ่งรายการ
• ตรรกะการประมวลผลจะเปลี่ยนแปลงพฤติกรรมของระบบ

คำถามภายนอก

External Inquiry (EQ) เป็นกระบวนการพื้นฐานที่ส่งข้อมูลหรือควบคุมข้อมูลนอกขอบเขต วัตถุประสงค์หลักของ EQ คือการนำเสนอข้อมูลแก่ผู้ใช้ผ่านการดึงข้อมูลหรือข้อมูลการควบคุม

ตรรกะการประมวลผลไม่มีสูตรทางคณิตศาสตร์หรือการคำนวณและไม่สร้างข้อมูลที่ได้รับ ไม่มีการบำรุงรักษา ILF ในระหว่างการประมวลผลและไม่มีการเปลี่ยนแปลงพฤติกรรมของระบบ

ต้องใช้กฎต่อไปนี้ทั้งหมด -

• ส่งข้อมูลหรือควบคุมข้อมูลภายนอกขอบเขตของแอปพลิเคชัน
• สำหรับ EP ที่ระบุต้องใช้หนึ่งในสามคำสั่ง -
  • ตรรกะการประมวลผลไม่เหมือนใครจากตรรกะการประมวลผลที่ดำเนินการโดย EQ อื่น ๆ สำหรับแอปพลิเคชัน
  • ชุดองค์ประกอบข้อมูลที่ระบุแตกต่างจาก EQ อื่น ๆ ในแอปพลิเคชัน
  • ILF หรือ EIF ที่อ้างถึงแตกต่างจากไฟล์ที่อ้างถึงโดย EQ อื่น ๆ ในแอปพลิเคชัน

นอกจากนี้ต้องใช้กฎต่อไปนี้ทั้งหมด -

• ตรรกะการประมวลผลดึงข้อมูลหรือควบคุมข้อมูลจาก ILF หรือ EIF
• ตรรกะการประมวลผลไม่มีสูตรทางคณิตศาสตร์หรือการคำนวณ
• ตรรกะการประมวลผลไม่ได้เปลี่ยนแปลงพฤติกรรมของระบบ
• ตรรกะการประมวลผลไม่รักษา ILF

ขั้นตอนที่ 6.2: นับ DET ​​สำหรับแต่ละฟังก์ชันธุรกรรม

ใช้กฎต่อไปนี้เพื่อนับ DET ​​สำหรับ EI -

• ตรวจสอบทุกสิ่งที่ข้าม (เข้าและ / หรือออก) ขอบเขต

• นับหนึ่ง DET สำหรับแอตทริบิวต์ที่ระบุตัวตนของผู้ใช้แต่ละรายที่ไม่ซ้ำกันซึ่งข้าม (เข้าและ / หรือออก) ขอบเขตระหว่างการประมวลผลฟังก์ชันทรานแซคชัน

• นับเพียงหนึ่ง DET ต่อฟังก์ชันการทำธุรกรรมสำหรับความสามารถในการส่งข้อความตอบกลับของแอปพลิเคชันแม้ว่าจะมีหลายข้อความก็ตาม

• นับเพียงหนึ่ง DET ต่อฟังก์ชันทรานแซคชันสำหรับความสามารถในการเริ่มต้นการดำเนินการแม้ว่าจะมีหลายวิธีก็ตาม

• อย่านับรายการต่อไปนี้เป็น DET -

  • แอตทริบิวต์ที่สร้างขึ้นภายในขอบเขตโดยฟังก์ชันการทำธุรกรรมและบันทึกลงใน ILF โดยไม่ต้องออกจากขอบเขต

  • ตัวอักษรเช่นชื่อรายงานตัวระบุหน้าจอหรือแผงส่วนหัวคอลัมน์และชื่อแอตทริบิวต์

  • แอปพลิเคชันสร้างตราประทับเช่นแอตทริบิวต์วันที่และเวลา

  • ตัวแปรการเพจหมายเลขหน้าและข้อมูลการกำหนดตำแหน่งเช่น 'แถวที่ 37 ถึง 54 จาก 211'

  • เครื่องมือช่วยในการนำทางเช่นความสามารถในการนำทางภายในรายการโดยใช้“ ก่อนหน้า”“ ถัดไป”“ แรก”“ สุดท้าย” และสิ่งที่เทียบเท่าแบบกราฟิก

ใช้กฎต่อไปนี้เพื่อนับ DET ​​สำหรับ EOs / EQs -

• ตรวจสอบทุกสิ่งที่ข้าม (เข้าและ / หรือออก) ขอบเขต

• นับหนึ่ง DET สำหรับแอตทริบิวต์ที่ระบุตัวตนของผู้ใช้แต่ละรายที่ไม่ซ้ำกันซึ่งข้าม (เข้าและ / หรือออก) ขอบเขตระหว่างการประมวลผลฟังก์ชันทรานแซคชัน

• นับเพียงหนึ่ง DET ต่อฟังก์ชันการทำธุรกรรมสำหรับความสามารถในการส่งข้อความตอบกลับของแอปพลิเคชันแม้ว่าจะมีหลายข้อความก็ตาม

• นับเพียงหนึ่ง DET ต่อฟังก์ชันทรานแซคชันสำหรับความสามารถในการเริ่มต้นการดำเนินการแม้ว่าจะมีหลายวิธีก็ตาม

• อย่านับรายการต่อไปนี้เป็น DET -

  • แอตทริบิวต์ที่สร้างขึ้นภายในขอบเขตโดยไม่ต้องข้ามขอบเขต

  • ตัวอักษรเช่นชื่อรายงานตัวระบุหน้าจอหรือแผงส่วนหัวคอลัมน์และชื่อแอตทริบิวต์

  • แอปพลิเคชันสร้างตราประทับเช่นแอตทริบิวต์วันที่และเวลา

  • ตัวแปรการเพจหมายเลขหน้าและข้อมูลการกำหนดตำแหน่งเช่น 'แถวที่ 37 ถึง 54 จาก 211'

  • เครื่องมือช่วยในการนำทางเช่นความสามารถในการนำทางภายในรายการโดยใช้“ ก่อนหน้า”“ ถัดไป”“ แรก”“ สุดท้าย” และสิ่งที่เทียบเท่าแบบกราฟิก

ขั้นตอนที่ 6.3: นับ FTR สำหรับแต่ละฟังก์ชันธุรกรรม

ใช้กฎต่อไปนี้เพื่อนับ FTR สำหรับ EI -

• นับ FTR สำหรับแต่ละ ILF ที่ดูแล
• นับ FTR สำหรับแต่ละ ILF หรือ EIF ที่อ่านระหว่างประมวลผล EI
• นับเพียงหนึ่ง FTR สำหรับแต่ละ ILF ที่ได้รับการดูแลและอ่าน

ใช้กฎต่อไปนี้เพื่อนับ FTR สำหรับ EO / EQ -

• นับ FTR สำหรับแต่ละ ILF หรือ EIF ที่อ่านระหว่างประมวลผล EP

นอกจากนี้ให้ใช้กฎต่อไปนี้เพื่อนับ FTR สำหรับ EO -

• นับ FTR สำหรับแต่ละ ILF ที่คงไว้ระหว่างการประมวลผลของ EP
• นับเพียงหนึ่ง FTR สำหรับแต่ละ ILF ที่ดูแลและอ่านโดย EP

ขั้นตอนที่ 6.4: กำหนดความซับซ้อนของฟังก์ชันสำหรับแต่ละฟังก์ชันของธุรกรรม

FTR	ประเภทองค์ประกอบข้อมูล (DET)
	1-4	5-15	>=16
0-1	ล	ล	ก
2	ล	ก	ซ
> = 3	ก	ซ	ซ

ความซับซ้อนในการทำงาน: L = ต่ำ; A = ค่าเฉลี่ย; H = สูง

กำหนดความซับซ้อนในการทำงานสำหรับแต่ละ EO / EQ โดยมีข้อยกเว้นว่า EQ ต้องมีค่า FTR อย่างน้อย 1 รายการ -

EQ ต้องมีอย่างน้อย 1 FTR FTR	ประเภทองค์ประกอบข้อมูล (DET)
	1-4	5-15	> = 16
0-1	ล	ล	ก
2	ล	ก	ซ
> = 3	ก	ซ	ซ

ความซับซ้อนในการทำงาน: L = ต่ำ; A = ค่าเฉลี่ย; H = สูง

ขั้นตอนที่ 6.5: วัดขนาดการทำงานสำหรับแต่ละฟังก์ชันการทำธุรกรรม

วัดขนาดการทำงานสำหรับแต่ละ EI จากความซับซ้อนในการทำงาน

ความซับซ้อน	นับ FP
ต่ำ	3
เฉลี่ย	4
สูง	6

วัดขนาดการทำงานสำหรับแต่ละ EO / EQ จากความซับซ้อนในการทำงาน

ความซับซ้อน	FP Count สำหรับ EO	FP Count สำหรับ EQ
ต่ำ	4	3
เฉลี่ย	5	4
สูง	6	6

ขั้นตอนที่ 7: คำนวณขนาดการทำงาน (จำนวนจุดของฟังก์ชันที่ยังไม่ได้ปรับ)

ในการคำนวณขนาดการใช้งานควรทำตามขั้นตอนด้านล่าง -

ขั้นตอนที่ 7.1

ระลึกถึงสิ่งที่คุณพบในขั้นตอนที่ 1 กำหนดประเภทของการนับ

ขั้นตอนที่ 7.2

คำนวณขนาดการทำงานหรือจำนวนจุดของฟังก์ชันตามประเภท

• สำหรับการนับคะแนนฟังก์ชันการพัฒนาไปที่ขั้นตอนที่ 7.3
• สำหรับการนับคะแนนฟังก์ชันแอปพลิเคชันไปที่ขั้นตอน 7.4
• สำหรับการนับคะแนนฟังก์ชันการปรับปรุงให้ไปที่ขั้นตอนที่ 7.5

ขั้นตอนที่ 7.3

การนับคะแนนฟังก์ชันการพัฒนาประกอบด้วยสององค์ประกอบของฟังก์ชันการทำงาน -

• ฟังก์ชันการทำงานของแอปพลิเคชันที่รวมอยู่ในข้อกำหนดของผู้ใช้สำหรับโครงการ

• ฟังก์ชันการแปลงที่รวมอยู่ในข้อกำหนดของผู้ใช้สำหรับโครงการ ฟังก์ชันการแปลงประกอบด้วยฟังก์ชันที่มีให้เฉพาะในการติดตั้งเพื่อแปลงข้อมูลและ / หรือให้ข้อกำหนดการแปลงอื่น ๆ ที่ผู้ใช้ระบุเช่นรายงานการแปลงพิเศษ เช่นโปรแกรมประยุกต์ที่มีอยู่อาจถูกแทนที่ด้วยระบบใหม่

DFP = ADD + CFP

ที่ไหน

DFP = การนับคะแนนฟังก์ชันการพัฒนา

ADD = ขนาดของฟังก์ชันที่ส่งมอบให้กับผู้ใช้โดยโครงการพัฒนา

CFP = ขนาดของฟังก์ชันการแปลง

ADD = FP Count (ILFs) + FP Count (EIFs) + FP Count (EIs) + FP Count (EOs) + FP Count (EQs)

CFP = FP Count (ILFs) + FP Count (EIFs) + FP Count (EIs) + FP Count (EOs) + FP Count (EQs)

ขั้นตอนที่ 7.4

คำนวณจำนวนจุดของฟังก์ชันแอปพลิเคชัน

AFP = ADD

ที่ไหน

AFP = จำนวนจุดของฟังก์ชันแอปพลิเคชัน

ADD = ขนาดของฟังก์ชันที่ส่งมอบให้กับผู้ใช้โดยโครงการพัฒนา (ไม่รวมขนาดของฟังก์ชันการแปลงใด ๆ ) หรือฟังก์ชันที่มีอยู่เมื่อใดก็ตามที่มีการนับแอปพลิเคชัน

ADD = FP Count (ILFs) + FP Count (EIFs) + FP Count (EIs) + FP Count (EOs) + FP Count (EQs)

ขั้นตอนที่ 7.5

Enhancement Function Point Count พิจารณาองค์ประกอบสี่ประการดังต่อไปนี้ -

• ฟังก์ชันที่เพิ่มลงในแอปพลิเคชัน
• ฟังก์ชันที่แก้ไขในแอปพลิเคชัน
• ฟังก์ชันการแปลง
• ฟังก์ชันที่ถูกลบออกจากแอปพลิเคชัน

EFP = ADD + CHGA + CFP + DEL

ที่ไหน

EFP = การนับคะแนนฟังก์ชันการเพิ่มประสิทธิภาพ

ADD = ขนาดของฟังก์ชันที่เพิ่มโดยโครงการปรับปรุง

CHGA = ขนาดของฟังก์ชันที่ถูกเปลี่ยนแปลงโดยโครงการปรับปรุง

CFP = ขนาดของฟังก์ชันการแปลง

DEL = ขนาดของฟังก์ชันที่ถูกลบโดยโครงการปรับปรุง

ADD = FP Count (ILFs) + FP Count (EIFs) + FP Count (EIs) + FP Count (EOs) + FP Count (EQs)

CHGA = FP Count (ILFs) + FP Count (EIFs) + FP Count (EIs) + FP Count (EOs) + FP Count (EQs)

CFP = FP Count (ILFs) + FP Count (EIFs) + FP Count (EIs) + FP Count (EOs) + FP Count (EQs)

DEL = จำนวน FP (ILF) + จำนวน FP (EIF) + FP COUNT (EIs) + จำนวน FP (EO) + จำนวน FP (EQ)

ขั้นตอนที่ 8: กำหนดปัจจัยการปรับมูลค่า

GSC เป็นทางเลือกใน CPM 4.3.1 และย้ายไปที่ภาคผนวก ดังนั้นขั้นตอนที่ 8 และขั้นตอนที่ 9 สามารถข้ามไปได้

Value Adjustment Factor (VAF) อ้างอิงจาก GSC 14 รายการที่ให้คะแนนการทำงานทั่วไปของแอปพลิเคชันที่นับ GSC เป็นข้อ จำกัด ทางธุรกิจของผู้ใช้โดยไม่ขึ้นอยู่กับเทคโนโลยี แต่ละลักษณะมีคำอธิบายที่เกี่ยวข้องเพื่อกำหนดระดับของอิทธิพล

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

ระดับของช่วงอิทธิพลอยู่ในระดับศูนย์ถึงห้าตั้งแต่ไม่มีอิทธิพลไปจนถึงอิทธิพลที่รุนแรง

คะแนน	ระดับของอิทธิพล
0	ไม่มีอยู่หรือไม่มีอิทธิพล
1	อิทธิพลโดยบังเอิญ
2	อิทธิพลปานกลาง
3	อิทธิพลโดยเฉลี่ย
4	อิทธิพลที่สำคัญ
5	มีอิทธิพลอย่างมากตลอด

กำหนดระดับอิทธิพลของ GSC ทั้ง 14 หน่วยงาน

ผลรวมของค่าของ 14 GSC ที่ได้รับจึงเรียกว่า Total Degree of Influence (TDI)

TDI = ∑¹⁴ Degrees of Influence

จากนั้นคำนวณ Value Adjustment Factor (VAF) เป็น

VAF = (TDI × 0.01) + 0.65

GSC แต่ละตัวสามารถเปลี่ยนแปลงได้ตั้งแต่ 0 ถึง 5 TDI อาจแตกต่างกันไปตั้งแต่ (0 × 14) ถึง (5 × 14) นั่นคือ 0 (เมื่อ GSC ทั้งหมดต่ำ) ถึง 70 (เมื่อ GSC ทั้งหมดสูง) เช่น 0 ≤ TDI ≤ 70 ดังนั้น VAF จึงสามารถเปลี่ยนแปลงได้ในช่วงตั้งแต่ 0.65 (เมื่อ GSC ทั้งหมดอยู่ในระดับต่ำ) ถึง 1.35 (เมื่อ GSC ทั้งหมดมีค่าสูง) เช่น 0.65 ≤ VAF ≤ 1.35

ขั้นตอนที่ 9: คำนวณจำนวนจุดของฟังก์ชันที่ปรับแล้ว

ตามแนวทาง FPA ที่ใช้ VAF (CPM เวอร์ชันก่อน V4.3.1) สิ่งนี้ถูกกำหนดโดย

Adjusted FP Count = Unadjusted FP Count × VAF

โดยที่จำนวน FP ที่ไม่ได้ปรับคือขนาดการทำงานที่คุณได้คำนวณไว้ในขั้นตอนที่ 7

เนื่องจาก VAF สามารถเปลี่ยนแปลงได้ตั้งแต่ 0.65 ถึง 1.35 VAF จึงมีอิทธิพล± 35% ต่อจำนวน FP ที่ปรับขั้นสุดท้าย

ประโยชน์ของ Function Points

จุดฟังก์ชันมีประโยชน์ -

• ในการวัดขนาดของสารละลายแทนขนาดของปัญหา.

• เนื่องจากข้อกำหนดเป็นสิ่งเดียวที่จำเป็นสำหรับการนับคะแนนฟังก์ชัน

• เนื่องจากเป็นอิสระจากเทคโนโลยี

• เนื่องจากเป็นอิสระจากภาษาโปรแกรม

• ในการประมาณโครงการทดสอบ

• ในการประมาณต้นทุนโครงการโดยรวมกำหนดการและความพยายาม

• ในการเจรจาสัญญาเนื่องจากเป็นวิธีการสื่อสารที่ง่ายขึ้นกับกลุ่มธุรกิจ

• เนื่องจากจะวัดปริมาณและกำหนดค่าให้กับการใช้งานจริงอินเตอร์เฟสและวัตถุประสงค์ของฟังก์ชันในซอฟต์แวร์

• ในการสร้างอัตราส่วนด้วยเมตริกอื่น ๆ เช่นชั่วโมงต้นทุนจำนวนพนักงานระยะเวลาและเมตริกแอปพลิเคชันอื่น ๆ

ที่เก็บ FP

International Software Benchmarking Standards Group (ISBSG) เติบโตและรักษาที่เก็บข้อมูลไอทีสองแห่ง

• โครงการพัฒนาและเพิ่มประสิทธิภาพ
• แอปพลิเคชันการบำรุงรักษาและการสนับสนุน

มีโครงการมากกว่า 6,000 โครงการในพื้นที่เก็บข้อมูลโครงการพัฒนาและเพิ่มประสิทธิภาพ

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

ใบอนุญาตที่เก็บ ISBSG สามารถซื้อได้จาก: http://www.isbsg.com/

ISBSG มอบส่วนลด 10% สำหรับสมาชิก IFPUG สำหรับการซื้อทางออนไลน์เมื่อใช้รหัสส่วนลด“ IFPUGMembers”

การอัปเดตข้อมูลโครงการซอฟต์แวร์ ISBSG สามารถพบได้ที่: http://www.ifpug.org/isbsg/

COSMIC และ IFPUG ร่วมมือกันจัดทำอภิธานศัพท์สำหรับซอฟต์แวร์ Non-functional และ Project Requirements สามารถดาวน์โหลดได้จาก - cosmic-sizing.org

ก Use-Case คือชุดของการโต้ตอบที่เกี่ยวข้องระหว่างผู้ใช้และระบบที่ช่วยให้ผู้ใช้บรรลุเป้าหมาย

Use-Cases เป็นวิธีการจับข้อกำหนดการทำงานของระบบ ผู้ใช้ระบบเรียกว่า 'Actor' Use-Cases โดยพื้นฐานแล้วอยู่ในรูปแบบข้อความ

Use-Case Points - คำจำกัดความ

Use-Case Points (UCP)เป็นเทคนิคการประมาณค่าซอฟต์แวร์ที่ใช้ในการวัดขนาดซอฟต์แวร์ด้วยกรณีการใช้งาน แนวคิดของ UCP คล้ายกับ FPs

จำนวน UCP ในโครงการจะขึ้นอยู่กับสิ่งต่อไปนี้ -

• จำนวนและความซับซ้อนของกรณีการใช้งานในระบบ
• จำนวนและความซับซ้อนของนักแสดงในระบบ

  • ข้อกำหนดที่ไม่สามารถใช้งานได้ต่างๆ (เช่นการพกพาประสิทธิภาพการบำรุงรักษา) ที่ไม่ได้เขียนเป็นกรณีการใช้งาน

  • สภาพแวดล้อมที่จะพัฒนาโครงการ (เช่นภาษาแรงจูงใจของทีม ฯลฯ )

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

ประวัติความเป็นมาของประเด็นการใช้งาน

วิธีการประมาณค่า Use-Case Point ได้รับการแนะนำโดย Gustav Karner ในปี 1993 งานนี้ได้รับอนุญาตจาก Rational Software ซึ่งรวมเข้ากับ IBM ในภายหลัง

กระบวนการนับคะแนน Use-Case

กระบวนการนับคะแนน Use-Case มีขั้นตอนดังต่อไปนี้ -

• คำนวณ UCP ที่ไม่ได้ปรับแต่ง
• ปรับความซับซ้อนทางเทคนิค
• ปรับความซับซ้อนของสิ่งแวดล้อม
• คำนวณ UCP ที่ปรับแล้ว

ขั้นตอนที่ 1: คำนวณคะแนนกรณีการใช้งานที่ไม่ได้ปรับเปลี่ยน

คุณคำนวณคะแนนการใช้งานที่ไม่ได้ปรับเปลี่ยนก่อนโดยทำตามขั้นตอนต่อไปนี้ -

• กำหนดน้ำหนักกรณีใช้งานที่ไม่ได้ปรับเปลี่ยน
• กำหนดน้ำหนักนักแสดงที่ไม่ได้ปรับแต่ง
• คำนวณคะแนนการใช้งานที่ไม่ได้ปรับเปลี่ยน

Step 1.1 - กำหนดน้ำหนักกรณีใช้งานที่ไม่ได้ปรับเปลี่ยน

Step 1.1.1 - ค้นหาจำนวนธุรกรรมในแต่ละกรณีการใช้งาน

หาก Use-Cases เขียนด้วย User Goal Levels ธุรกรรมจะเทียบเท่ากับขั้นตอนใน Use-Case ค้นหาจำนวนธุรกรรมโดยการนับขั้นตอนใน Use-Case

Step 1.1.2- จัดประเภทการใช้งานแต่ละกรณีเป็นแบบธรรมดาเฉลี่ยหรือซับซ้อนตามจำนวนธุรกรรมใน Use-Case นอกจากนี้ให้กำหนด Use-Case Weight ดังแสดงในตารางต่อไปนี้ -

ความซับซ้อนของการใช้กรณี	จำนวนธุรกรรม	น้ำหนักกรณีใช้งาน
เรียบง่าย	≤3	5
เฉลี่ย	4 ถึง 7	10
ซับซ้อน	> 7	15

Step 1.1.3- ทำซ้ำสำหรับแต่ละ Use-Case และรับ Use-Case Weights ทั้งหมด น้ำหนักการใช้งานที่ไม่ได้ปรับเปลี่ยน (UUCW) คือผลรวมของน้ำหนักกรณีใช้งานทั้งหมด

Step 1.1.4 - ค้นหา Use-Case Weight (UUCW) ที่ไม่ได้ปรับเปลี่ยนโดยใช้ตารางต่อไปนี้ -

ความซับซ้อนของการใช้กรณี	น้ำหนักกรณีใช้งาน	จำนวนกรณีการใช้งาน	สินค้า
เรียบง่าย	5	NSUC	5 × NSUC
เฉลี่ย	10	NAUC	10 × NAUC
ซับซ้อน	15	NCUC	15 × NCUC
Unadjusted Use-Case Weight (UUCW)			5 × NSUC + 10 × NAUC + 15 × NCUC

ที่ไหน

NSUC คือหมายเลข กรณีใช้งานง่าย

NAUC คือหมายเลข จำนวนกรณีการใช้งานโดยเฉลี่ย

NCUC คือหมายเลข กรณีการใช้งานที่ซับซ้อน

Step 1.2 - กำหนดน้ำหนักนักแสดงที่ไม่ได้ปรับแต่ง

นักแสดงในกรณีการใช้งานอาจเป็นบุคคลโปรแกรมอื่น ฯลฯ นักแสดงบางคนเช่นระบบที่มี API ที่กำหนดมีความต้องการที่ง่ายมากและเพิ่มความซับซ้อนของ Use-Case เพียงเล็กน้อย

ตัวแสดงบางตัวเช่นระบบที่โต้ตอบผ่านโปรโตคอลมีความต้องการมากขึ้นและเพิ่มความซับซ้อนของ Use-Case ในระดับหนึ่ง

นักแสดงคนอื่น ๆ เช่นผู้ใช้ที่โต้ตอบผ่าน GUI มีผลกระทบอย่างมากต่อความซับซ้อนของ Use-Case จากความแตกต่างเหล่านี้คุณสามารถแบ่งประเภทของนักแสดงเป็นง่ายปานกลางและซับซ้อน

Step 1.2.1 - จัดประเภทนักแสดงเป็นแบบธรรมดาเฉลี่ยและซับซ้อนและกำหนดน้ำหนักนักแสดงดังแสดงในตารางต่อไปนี้ -

ความซับซ้อนของนักแสดง	ตัวอย่าง	น้ำหนักนักแสดง
เรียบง่าย	ระบบที่มี API ที่กำหนด	1
เฉลี่ย	ระบบโต้ตอบผ่านโปรโตคอล	2
ซับซ้อน	ผู้ใช้โต้ตอบผ่าน GUI	3

Step 1.2.2- ทำซ้ำสำหรับนักแสดงแต่ละคนและรับน้ำหนักนักแสดงทั้งหมด น้ำหนักนักแสดงที่ไม่ได้ปรับแต่ง (UAW) คือผลรวมของน้ำหนักนักแสดงทั้งหมด

Step 1.2.3 - ค้นหาน้ำหนักนักแสดงที่ไม่ได้ปรับแต่ง (UAW) โดยใช้ตารางต่อไปนี้ -

ความซับซ้อนของนักแสดง	น้ำหนักนักแสดง	จำนวนนักแสดง	สินค้า
เรียบง่าย	1	NSA	1 × NSA
เฉลี่ย	2	NAA	2 × NAA
ซับซ้อน	3	NCA	3 × NCA
Unadjusted Actor Weight (UAW)			1 × NSA + 2 × NAA + 3 × NCA

ที่ไหน

NSA คือหมายเลข ของ Simple Actors

NAA คือหมายเลข ของนักแสดงเฉลี่ย

NCA คือหมายเลข ของนักแสดงที่ซับซ้อน

Step 1.3 - คำนวณคะแนนการใช้งานที่ไม่ได้ปรับเปลี่ยน

น้ำหนักกรณีใช้งานที่ไม่ได้ปรับแต่ง (UUCW) และน้ำหนักตัวแสดงที่ไม่ได้ปรับแต่ง (UAW) จะให้ขนาดที่ไม่ได้ปรับแต่งของระบบซึ่งเรียกว่าจุดกรณีใช้งานที่ไม่ได้ปรับแต่ง

Unadjusted Use-Case Points (UUCP) = UUCW + UAW

ขั้นตอนต่อไปคือการปรับคะแนนกรณีการใช้งานที่ไม่ได้ปรับเปลี่ยน (UUCP) สำหรับความซับซ้อนทางเทคนิคและความซับซ้อนด้านสิ่งแวดล้อม

ขั้นตอนที่ 2: ปรับเพื่อความซับซ้อนทางเทคนิค

Step 2.1 - พิจารณาปัจจัย 13 ประการที่นำไปสู่ผลกระทบของความซับซ้อนทางเทคนิคของโครงการเกี่ยวกับ Use-Case Points และน้ำหนักที่เกี่ยวข้องตามที่ระบุในตารางต่อไปนี้ -

ปัจจัย	คำอธิบาย	น้ำหนัก
T1	ระบบกระจาย	2.0
T2	เวลาตอบสนองหรือวัตถุประสงค์ประสิทธิภาพปริมาณงาน	1.0
T3	ประสิทธิภาพของผู้ใช้ปลายทาง	1.0
T4	การประมวลผลภายในที่ซับซ้อน	1.0
T5	รหัสต้องใช้ซ้ำได้	1.0
T6	ติดตั้งง่าย	.5
T7	ง่ายต่อการใช้	.5
T8	แบบพกพา	2.0
T9	ง่ายต่อการเปลี่ยนแปลง	1.0
T10	พร้อมกัน	1.0
T11	รวมถึงวัตถุประสงค์ด้านความปลอดภัยพิเศษ	1.0
T12	ให้การเข้าถึงโดยตรงสำหรับบุคคลที่สาม	1.0
T13	จำเป็นต้องมีสิ่งอำนวยความสะดวกการฝึกอบรมผู้ใช้พิเศษ	1.0

หลายปัจจัยเหล่านี้แสดงถึงข้อกำหนดที่ไม่สามารถใช้งานได้ของโครงการ

Step 2.2 - สำหรับแต่ละปัจจัย 13 ประการให้ประเมินโครงการและให้คะแนนจาก 0 (ไม่เกี่ยวข้อง) ถึง 5 (สำคัญมาก)

Step 2.3 - คำนวณผลกระทบของปัจจัยจากน้ำหนักผลกระทบของปัจจัยและค่านิยมสำหรับโครงการเป็น

Impact of the Factor = Impact Weight × Rated Value

Step (2.4)- คำนวณผลรวมของผลกระทบของปัจจัยทั้งหมด สิ่งนี้ให้ค่า Total Technical Factor (TFactor) ตามที่ระบุในตารางด้านล่าง -

ปัจจัย	คำอธิบาย	น้ำหนัก (W)	ค่านิยม (0 ถึง 5) (RV)	ผลกระทบ (I = W × RV)
T1	ระบบกระจาย	2.0
T2	เวลาตอบสนองหรือวัตถุประสงค์ประสิทธิภาพปริมาณงาน	1.0
T3	ประสิทธิภาพของผู้ใช้ปลายทาง	1.0
T4	การประมวลผลภายในที่ซับซ้อน	1.0
T5	รหัสต้องใช้ซ้ำได้	1.0
T6	ติดตั้งง่าย	.5
T7	ง่ายต่อการใช้	.5
T8	แบบพกพา	2.0
T9	ง่ายต่อการเปลี่ยนแปลง	1.0
T10	พร้อมกัน	1.0
T11	รวมถึงวัตถุประสงค์ด้านความปลอดภัยพิเศษ	1.0
T12	ให้การเข้าถึงโดยตรงสำหรับบุคคลที่สาม	1.0
T13	จำเป็นต้องมีสิ่งอำนวยความสะดวกการฝึกอบรมผู้ใช้พิเศษ	1.0
Total Technical Factor (TFactor)

Step 2.5 - คำนวณ Technical Complexity Factor (TCF) เป็น -

TCF = 0.6 + (0.01 × TFactor)

ขั้นตอนที่ 3: ปรับเปลี่ยนเพื่อความซับซ้อนของสิ่งแวดล้อม

Step 3.1 - พิจารณาปัจจัยด้านสิ่งแวดล้อม 8 ประการที่อาจมีผลต่อการดำเนินโครงการและน้ำหนักที่สอดคล้องกันตามตารางต่อไปนี้ -

ปัจจัย	คำอธิบาย	น้ำหนัก
F1	คุ้นเคยกับรูปแบบโครงการที่นำมาใช้	1.5
F2	ประสบการณ์การใช้งาน	.5
F3	ประสบการณ์เชิงวัตถุ	1.0
F4	ความสามารถในการวิเคราะห์ลูกค้าเป้าหมาย	.5
F5	แรงจูงใจ	1.0
F6	ข้อกำหนดที่มั่นคง	2.0
F7	พนักงานพาร์ทไทม์	-1.0
F8	ภาษาโปรแกรมยาก	-1.0

Step 3.2 - สำหรับแต่ละปัจจัยทั้ง 8 ให้ประเมินโครงการและให้คะแนนจาก 0 (ไม่เกี่ยวข้อง) ถึง 5 (สำคัญมาก)

Step 3.3 - คำนวณผลกระทบของปัจจัยจากน้ำหนักผลกระทบของปัจจัยและค่านิยมสำหรับโครงการเป็น

Impact of the Factor = Impact Weight × Rated Value

Step 3.4- คำนวณผลรวมของผลกระทบของปัจจัยทั้งหมด สิ่งนี้ให้ค่า Total Environment Factor (EFactor) ตามที่ระบุในตารางต่อไปนี้ -

ปัจจัย	คำอธิบาย	น้ำหนัก (W)	ค่านิยม (0 ถึง 5) (RV)	ผลกระทบ (I = W × RV)
F1	คุ้นเคยกับรูปแบบโครงการที่นำมาใช้	1.5
F2	ประสบการณ์การใช้งาน	.5
F3	ประสบการณ์เชิงวัตถุ	1.0
F4	ความสามารถในการวิเคราะห์ลูกค้าเป้าหมาย	.5
F5	แรงจูงใจ	1.0
F6	ข้อกำหนดที่มั่นคง	2.0
F7	พนักงานพาร์ทไทม์	-1.0
F8	ภาษาโปรแกรมยาก	-1.0
Total Environment Factor (EFactor)

Step 3.5 - คำนวณปัจจัยด้านสิ่งแวดล้อม (EF) เป็น -

1.4 + (-0.03 × EFactor)

ขั้นตอนที่ 4: คำนวณคะแนนกรณีการใช้งานที่ปรับแล้ว (UCP)

คำนวณคะแนนกรณีการใช้งานที่ปรับแล้ว (UCP) เป็น -

UCP = UUCP × TCF × EF

ข้อดีและข้อเสียของ Use-Case Points

ข้อดีของ Use-Case Points

• UCP ขึ้นอยู่กับกรณีการใช้งานและสามารถวัดได้ในช่วงต้นของวงจรชีวิตของโครงการ

• UCP (การประมาณขนาด) จะไม่ขึ้นอยู่กับขนาดทักษะและประสบการณ์ของทีมที่ดำเนินโครงการ

• การประมาณการตาม UCP พบว่าใกล้เคียงกับความเป็นจริงเมื่อดำเนินการประมาณโดยผู้มีประสบการณ์

• UCP ใช้งานง่ายและไม่เรียกร้องให้มีการวิเคราะห์เพิ่มเติม

• กรณีการใช้งานถูกนำมาใช้อย่างมากมายเพื่อเป็นทางเลือกในการอธิบายข้อกำหนด ในกรณีเช่นนี้ UCP เป็นเทคนิคการประมาณค่าที่เหมาะสมที่สุด

ข้อเสียของ Use-Case Points

• UCP สามารถใช้ได้เฉพาะเมื่อข้อกำหนดถูกเขียนในรูปแบบของกรณีการใช้งาน

• ขึ้นอยู่กับกรณีการใช้งานที่มุ่งเน้นเป้าหมายเป็นลายลักษณ์อักษร หากกรณีการใช้งานไม่ดีหรือมีโครงสร้างที่สม่ำเสมอ UCP ที่ได้อาจไม่ถูกต้อง

• ปัจจัยทางเทคนิคและสิ่งแวดล้อมมีผลกระทบสูงต่อ UCP ต้องใช้ความระมัดระวังในขณะที่กำหนดค่าให้กับปัจจัยทางเทคนิคและสิ่งแวดล้อม

• UCP มีประโยชน์สำหรับการประเมินขนาดโครงการโดยรวมในเบื้องต้น แต่มีประโยชน์น้อยกว่ามากในการขับเคลื่อนงานการวนซ้ำเพื่อทำซ้ำของทีม

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

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

Delphi Method ได้รับการพัฒนาในปี 1950-1960 ที่ RAND Corporation

เทคนิคเดลฟีแบบไวด์แบนด์

ในปี 1970 Barry Boehm และ John A.Farquhar ได้กำเนิด Wideband Variant ของ Delphi Method คำว่า "ไวด์แบนด์" ถูกนำมาใช้เนื่องจากเมื่อเทียบกับวิธีเดลฟีแล้วเทคนิคเดลฟีแบบไวด์แบนด์จะเกี่ยวข้องกับปฏิสัมพันธ์และการสื่อสารระหว่างผู้เข้าร่วมมากขึ้น

ในเทคนิค Wideband Delphi ทีมประเมินประกอบด้วยผู้จัดการโครงการผู้ดูแลผู้เชี่ยวชาญและตัวแทนจากทีมพัฒนาซึ่งประกอบด้วยทีมสมาชิก 3-7 คน มีการประชุมสองครั้ง -

• การประชุมคิกออฟ
• การประชุมประมาณการ

Wideband Delphi Technique - ขั้นตอน

Step 1 - เลือกทีมประมาณการและผู้ดูแล

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

Step 3 - จากนั้นสมาชิกในทีม Estimation แต่ละคนจะสร้าง WBS โดยละเอียดประเมินแต่ละงานใน WBS และจัดทำเอกสารสมมติฐานที่ตั้งไว้

Step 4- ผู้ดูแลเรียกทีมประมาณการสำหรับการประชุมประมาณการ หากสมาชิกทีมประมาณการคนใดคนหนึ่งตอบว่าการประมาณการยังไม่พร้อมผู้ดูแลจะให้เวลามากขึ้นและส่งคำเชิญเข้าร่วมประชุมอีกครั้ง

Step 5 - ทีมประมาณการทั้งหมดรวมตัวกันสำหรับการประชุมประมาณ

Step 5.1 - ในช่วงเริ่มต้นของการประชุมประมาณการผู้ดูแลจะรวบรวมค่าประมาณเริ่มต้นจากสมาชิกในทีมแต่ละคน

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

Step 5.3- สมาชิกในทีมแต่ละคนอ่านออกเสียงรายการงานโดยละเอียดที่ตนทำระบุสมมติฐานใด ๆ ที่เกิดขึ้นและตั้งคำถามหรือประเด็นใด ๆ ไม่มีการเปิดเผยประมาณการงาน

รายการงานโดยละเอียดแต่ละรายการมีส่วนช่วยให้รายการงานสมบูรณ์ยิ่งขึ้นเมื่อรวมกัน

Step 5.4 - จากนั้นทีมจะหารือเกี่ยวกับข้อสงสัย / ปัญหาที่พวกเขามีเกี่ยวกับงานที่พวกเขามาถึงข้อสันนิษฐานและปัญหาการประมาณ

Step 5.5- จากนั้นสมาชิกในทีมแต่ละคนจะทบทวนรายการงานและสมมติฐานของตนและทำการเปลี่ยนแปลงหากจำเป็น การประมาณการงานอาจต้องมีการปรับเปลี่ยนตามการอภิปรายซึ่งระบุไว้เป็น + N Hrs เพื่อความพยายามมากขึ้นและ –N ชม. เพื่อความพยายามน้อยลง

จากนั้นสมาชิกในทีมจะรวมการเปลี่ยนแปลงในการประมาณการงานเพื่อให้ได้ค่าประมาณโครงการทั้งหมด

Step 5.6 - ผู้ดูแลรวบรวมการประมาณการที่เปลี่ยนแปลงจากสมาชิกในทีมทั้งหมดและวางแผนไว้ในบรรทัดรอบ 2

ในรอบนี้ช่วงจะแคบลงเมื่อเทียบกับช่วงก่อนหน้าเนื่องจากขึ้นอยู่กับความเห็นพ้องต้องกันมากกว่า

Step 5.7 - จากนั้นทีมจะหารือเกี่ยวกับการปรับเปลี่ยนงานที่พวกเขาทำและสมมติฐาน

Step 5.8- จากนั้นสมาชิกในทีมแต่ละคนจะทบทวนรายการงานและสมมติฐานของตนและทำการเปลี่ยนแปลงหากจำเป็น การประมาณการงานอาจต้องมีการปรับเปลี่ยนตามการอภิปราย

จากนั้นสมาชิกในทีมจะรวมการเปลี่ยนแปลงในการประมาณการงานอีกครั้งเพื่อให้ได้ค่าประมาณโครงการทั้งหมด

Step 5.9 - ผู้ดูแลรวบรวมการประมาณการที่เปลี่ยนแปลงจากสมาชิกทั้งหมดอีกครั้งและวางแผนไว้ในบรรทัดรอบ 3

อีกครั้งในรอบนี้ช่วงจะแคบลงเมื่อเทียบกับช่วงก่อนหน้านี้

Step 5.10 - ทำซ้ำขั้นตอนที่ 5.7, 5.8, 5.9 จนกว่าจะตรงตามเกณฑ์ข้อใดข้อหนึ่งต่อไปนี้ -

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

Step 6 - จากนั้นผู้จัดการโครงการจะรวบรวมผลลัพธ์จากการประชุมประมาณการ

Step 6.1 - เขารวบรวมรายการงานแต่ละรายการและค่าประมาณที่เกี่ยวข้องไว้ในรายการงานหลักเดียว

Step 6.2 - เขายังรวมรายการสมมติฐานแต่ละรายการ

Step 6.3 - จากนั้นเขาจะตรวจสอบรายการงานขั้นสุดท้ายกับทีมประมาณการ

ข้อดีและข้อเสียของเทคนิคเดลฟีแบบไวด์แบนด์

ข้อดี

• Wideband Delphi Technique เป็นเทคนิคการประมาณโดยใช้ฉันทามติสำหรับการประมาณค่าความพยายาม
• มีประโยชน์ในการประมาณเวลาในการทำงาน
• การมีส่วนร่วมของผู้มีประสบการณ์และการประเมินเป็นรายบุคคลจะนำไปสู่ผลลัพธ์ที่เชื่อถือได้
• ผู้ที่จะทำงานนี้กำลังทำการประมาณจึงทำการประมาณการที่ถูกต้อง
• การไม่เปิดเผยตัวตนตลอดเวลาทำให้ทุกคนสามารถแสดงผลลัพธ์ได้อย่างมั่นใจ
• เทคนิคง่ายๆ
• มีการบันทึกข้อสมมติฐานหารือและตกลงกัน

ข้อเสีย

• จำเป็นต้องมีการสนับสนุนด้านการจัดการ
• ผลการประมาณอาจไม่ใช่สิ่งที่ผู้บริหารอยากได้ยิน

การประมาณค่าสามจุดดูที่ค่าสามค่า -

• การประมาณในแง่ดีที่สุด (O)
• ค่าประมาณที่เป็นไปได้มากที่สุด (M) และ
• การประมาณในแง่ร้าย (ค่าประมาณน้อยที่สุด (L))

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

การประมาณค่าสามจุด (E) ขึ้นอยู่กับค่าเฉลี่ยอย่างง่ายและเป็นไปตามการแจกแจงรูปสามเหลี่ยม

E = (O + M + L) / 3

ส่วนเบี่ยงเบนมาตรฐาน

ในการแจกแจงแบบสามเหลี่ยม

ค่าเฉลี่ย = (O + M + L) / 3

ค่าเบี่ยงเบนมาตรฐาน = √ [((O - E) ² + (M - E) ² + (L - E) ² ) / 2]

ขั้นตอนการประมาณค่าสามจุด

Step 1 - มาถึง WBS

Step 2 - สำหรับแต่ละงานให้ค้นหาค่าสามค่า - ค่าประมาณในแง่ดีที่สุด (O), ค่าประมาณที่เป็นไปได้มากที่สุด (M) และค่าประมาณในแง่ร้าย (L)

Step 3 - คำนวณค่าเฉลี่ยของทั้งสามค่า

Mean = (O + M + L) / 3

Step 4- คำนวณค่าประมาณสามจุดของงาน ค่าประมาณสามจุดคือค่าเฉลี่ย ดังนั้น

E = Mean = (O + M + L) / 3

Step 5 - คำนวณค่าเบี่ยงเบนมาตรฐานของงาน

Standard Deviation (SD) = √ [((O − E)² + (M − E)² + (L - E)²)/2]

Step 6 - ทำซ้ำขั้นตอนที่ 2, 3, 4 สำหรับงานทั้งหมดใน WBS

Step 7 - คำนวณค่าประมาณสามจุดของโครงการ

E (Project) = ∑ E (Task)

Step 8 - คำนวณค่าเบี่ยงเบนมาตรฐานของโครงการ

SD (Project) = √ (∑SD (Task)²)

แปลงค่าประมาณโครงการเป็นระดับความเชื่อมั่น

ค่าประมาณสามจุด (E) และค่าเบี่ยงเบนมาตรฐาน (SD) ที่คำนวณจึงใช้เพื่อแปลงค่าประมาณของโครงการเป็น "ระดับความเชื่อมั่น"

การแปลงเป็นไปตามนั้น -

• ระดับความเชื่อมั่นใน E +/– SD อยู่ที่ประมาณ 68%
• ระดับความเชื่อมั่นในค่า E +/– 1.645 × SD อยู่ที่ประมาณ 90%
• ระดับความเชื่อมั่นในค่า E +/– 2 × SD อยู่ที่ประมาณ 95%
• ระดับความเชื่อมั่นในค่า E +/– 3 × SD อยู่ที่ประมาณ 99.7%

โดยทั่วไประดับความเชื่อมั่น 95% คือ E Value + 2 × SD จะใช้สำหรับการประมาณการโครงการและงานทั้งหมด

การประเมินโครงการและเทคนิคการทบทวน (PERT) จะพิจารณาค่าสามค่า ได้แก่ ค่าประมาณในแง่ดีที่สุด (O) ค่าประมาณที่เป็นไปได้มากที่สุด (M) และค่าประมาณในแง่ร้าย (ค่าประมาณที่เป็นไปได้น้อยที่สุด (L)) มีความสับสนเกี่ยวกับการประมาณค่าสามจุดและ PERT ในอุตสาหกรรม อย่างไรก็ตามเทคนิคที่แตกต่างกัน คุณจะเห็นความแตกต่างเมื่อเรียนรู้เทคนิคทั้งสอง นอกจากนี้ในตอนท้ายของบทนี้ความแตกต่างจะถูกจัดเรียงและนำเสนอ

PERT ขึ้นอยู่กับค่าสามค่า - ค่าประมาณในแง่ดีที่สุด (O), ค่าประมาณที่เป็นไปได้มากที่สุด (M) และค่าประมาณในแง่ร้าย (ค่าประมาณที่มีโอกาสน้อยที่สุด (L)) ค่าประมาณที่เป็นไปได้มากที่สุดจะถ่วงน้ำหนักมากกว่าประมาณการอีก 2 รายการ 4 เท่า (ในแง่ดีและแง่ร้าย)

ค่าประมาณ PERT (E) ขึ้นอยู่กับค่าเฉลี่ยถ่วงน้ำหนักและเป็นไปตามการแจกแจงแบบเบต้า

E = (O + 4 × M + L)/6

มักใช้ PERT ร่วมกับ Critical Path Method (CPM) CPM บอกเกี่ยวกับงานที่มีความสำคัญในโครงการ หากงานเหล่านี้มีความล่าช้าโครงการจะล่าช้า

ส่วนเบี่ยงเบนมาตรฐาน

Standard Deviation (SD) วัดความแปรปรวนหรือความไม่แน่นอนในการประมาณการ

ในการแจกแจงเบต้า

ค่าเฉลี่ย = (O + 4 × M + L) / 6

ค่าเบี่ยงเบนมาตรฐาน (SD) = (L - O) / 6

ขั้นตอนการประมาณค่า PERT

Step (1) - มาถึง WBS

Step (2) - สำหรับแต่ละงานให้ค้นหาค่าประมาณในแง่ดีที่สุดสามค่า (O) ค่าประมาณที่เป็นไปได้มากที่สุด (M) และค่าประมาณในแง่ร้าย (L)

Step (3) - ค่าเฉลี่ย PERT = (O + 4 × M + L) / 6

ค่าเฉลี่ย PERT = (O + 4 × M + L) / 3

Step (4) - คำนวณค่าเบี่ยงเบนมาตรฐานของงาน

ค่าเบี่ยงเบนมาตรฐาน (SD) = (L - O) / 6

Step (6) - ทำซ้ำขั้นตอนที่ 2, 3, 4 สำหรับงานทั้งหมดใน WBS

Step (7) - คำนวณค่าประมาณ PERT ของโครงการ

E (โครงการ) = ∑ E (งาน)

Step (8) - คำนวณค่าเบี่ยงเบนมาตรฐานของโครงการ

SD (โครงการ) = √ (ΣSD (งาน) ² )

แปลงค่าประมาณโครงการเป็นระดับความเชื่อมั่น

ค่าประมาณ PERT (E) และส่วนเบี่ยงเบนมาตรฐาน (SD) ที่คำนวณจึงใช้เพื่อแปลงค่าประมาณของโครงการเป็นระดับความเชื่อมั่น

การแปลงเป็นไปตามนั้น

• ระดับความเชื่อมั่นใน E +/– SD อยู่ที่ประมาณ 68%
• ระดับความเชื่อมั่นในค่า E +/– 1.645 × SD อยู่ที่ประมาณ 90%
• ระดับความเชื่อมั่นในค่า E +/– 2 × SD อยู่ที่ประมาณ 95%
• ระดับความเชื่อมั่นในค่า E +/– 3 × SD อยู่ที่ประมาณ 99.7%

โดยทั่วไประดับความเชื่อมั่น 95% คือ E Value + 2 × SD จะใช้สำหรับการประมาณการโครงการและงานทั้งหมด

ความแตกต่างระหว่างการประมาณค่าสามจุดและ PERT

ต่อไปนี้คือความแตกต่างระหว่างการประมาณค่าสามจุดและ PERT -

การประมาณค่าสามจุด	ฮึกเหิม
ค่าเฉลี่ยอย่างง่าย	ค่าเฉลี่ยถ่วงน้ำหนัก
ติดตามการกระจายสามเหลี่ยม	ติดตามการกระจายเบต้า
ใช้สำหรับโครงการขนาดเล็กซ้ำ ๆ	ใช้สำหรับโครงการขนาดใหญ่ที่ไม่ซ้ำซากโดยปกติจะเป็นโครงการ R&D ใช้ร่วมกับ Critical Path Method (CPM)
E = ค่าเฉลี่ย = (O + M + L) / 3 นี่คือค่าเฉลี่ยอย่างง่าย	E = ค่าเฉลี่ย = (O + 4 × M + L) / 6 นี่คือค่าเฉลี่ยถ่วงน้ำหนัก
SD = √ [((O - E) 2 + (M - E) 2 + (L - E) 2 ) / 2]	SD = (L - O) / 6

Analogous Estimationใช้ข้อมูลโครงการในอดีตที่คล้ายกันในการประมาณระยะเวลาหรือต้นทุนของโครงการปัจจุบันของคุณดังนั้นคำว่า "การเปรียบเทียบ" คุณสามารถใช้การประมาณแบบอะนาล็อกเมื่อมีข้อมูล จำกัด เกี่ยวกับโครงการปัจจุบันของคุณ

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

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

การประมาณแบบอะนาล็อก - คำจำกัดความ

การประมาณค่าแบบอะนาล็อกเป็นเทคนิคที่ใช้ค่าของพารามิเตอร์จากข้อมูลในอดีตเป็นพื้นฐานในการประมาณค่าพารามิเตอร์ที่คล้ายกันสำหรับกิจกรรมในอนาคต ตัวอย่างพารามิเตอร์: ขอบเขตต้นทุนและระยะเวลา การวัดตัวอย่างเครื่องชั่ง - ขนาดน้ำหนักและความซับซ้อน

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

ข้อกำหนดการประมาณค่าแบบอะนาล็อก

สำหรับการประมาณค่าแบบอะนาล็อกต่อไปนี้เป็นข้อกำหนด -

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

ขั้นตอนการประมาณค่าแบบอะนาล็อก

ผู้จัดการโครงการและทีมงานต้องทำการประมาณค่าแบบอะนาล็อกร่วมกัน

• Step 1 - ระบุโดเมนของโครงการปัจจุบัน

• Step 2 - ระบุเทคโนโลยีของโครงการปัจจุบัน

• Step 3- ดูในฐานข้อมูลขององค์กรว่ามีข้อมูลโครงการที่คล้ายกันหรือไม่ หากมีให้ไปที่ขั้นตอนที่ (4) หรือไปที่ขั้นตอนที่ (6)

• Step 4 - เปรียบเทียบโครงการปัจจุบันกับข้อมูลโครงการในอดีตที่ระบุ

• Step 5- มาถึงระยะเวลาและประมาณการต้นทุนของโครงการปัจจุบัน สิ่งนี้จะสิ้นสุดการประมาณค่าที่คล้ายคลึงกันของโครงการ

• Step 6 - ดูในฐานข้อมูลขององค์กรว่าโครงการที่ผ่านมามีโมดูลที่คล้ายคลึงกับโครงการปัจจุบันหรือไม่

• Step 7 - ดูในฐานข้อมูลขององค์กรว่าโครงการที่ผ่านมามีกิจกรรมที่คล้ายคลึงกับโครงการปัจจุบันหรือไม่

• Step 8 - รวบรวมสิ่งเหล่านี้ทั้งหมดและใช้วิจารณญาณของผู้เชี่ยวชาญเพื่อให้มาถึงระยะเวลาและการประมาณค่าใช้จ่ายของโครงการปัจจุบัน

ข้อดีของการประมาณค่าแบบอะนาล็อก

• การประมาณแบบอะนาล็อกเป็นวิธีที่ดีกว่าในการประมาณค่าในขั้นตอนเริ่มต้นของโครงการเมื่อทราบรายละเอียดน้อยมาก

• เทคนิคนี้ง่ายและใช้เวลาในการประมาณน้อยมาก

• อัตราความสำเร็จขององค์กรสามารถคาดหวังได้สูงเนื่องจากเทคนิคนี้ขึ้นอยู่กับข้อมูลโครงการในอดีตขององค์กร

• การประมาณแบบอะนาล็อกสามารถใช้เพื่อประมาณความพยายามและระยะเวลาของงานแต่ละงานได้เช่นกัน ดังนั้นใน WBS เมื่อคุณประเมินงานคุณสามารถใช้ Analogy ได้

โครงสร้างการแบ่งงาน (WBS) ในการจัดการโครงการและวิศวกรรมระบบคือการย่อยสลายโครงการที่มุ่งเน้นการส่งมอบให้เป็นส่วนประกอบขนาดเล็ก WBS เป็นโครงการหลักที่ส่งมอบได้ซึ่งจัดระเบียบงานของทีมให้เป็นส่วนที่จัดการได้ องค์ความรู้การจัดการโครงการ (PMBOK) กำหนด WBS ว่าเป็น "การย่อยสลายตามลำดับชั้นที่มุ่งเน้นการส่งมอบของงานที่จะดำเนินการโดยทีมงานโครงการ"

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

การเป็นตัวแทนของ WBS

WBS แสดงเป็นรายการกิจกรรมการทำงานของโครงการตามลำดับชั้น WBS มีสองรูปแบบ -

• มุมมองเค้าร่าง (รูปแบบเยื้อง)
• มุมมองโครงสร้างต้นไม้ (แผนผังองค์กร)

ก่อนอื่นให้เราพูดถึงวิธีการใช้มุมมองเค้าร่างในการเตรียม WBS

มุมมองเค้าร่าง

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

• Software Development

• Scope

  • กำหนดขอบเขตโครงการ
  • การสนับสนุนโครงการที่ปลอดภัย
  • กำหนดทรัพยากรเบื้องต้น
  • รักษาความปลอดภัยทรัพยากรหลัก
  • ขอบเขตเสร็จสมบูรณ์

• Analysis/Software Requirements

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

• Design

  • ตรวจสอบข้อกำหนดเบื้องต้นของซอฟต์แวร์
  • พัฒนาข้อกำหนดการทำงาน
  • รับการอนุมัติเพื่อดำเนินการต่อ
  • การออกแบบเสร็จสมบูรณ์

• Development

  • ตรวจสอบข้อกำหนดการทำงาน
  • ระบุพารามิเตอร์การออกแบบโมดูลาร์ / ชั้น
  • พัฒนาโค้ด
  • การทดสอบของนักพัฒนา (การดีบักหลัก)
  • การพัฒนาเสร็จสมบูรณ์

• Testing

  • พัฒนาแผนการทดสอบหน่วยโดยใช้ข้อมูลจำเพาะของผลิตภัณฑ์
  • พัฒนาแผนการทดสอบการรวมโดยใช้ข้อมูลจำเพาะของผลิตภัณฑ์

• Training

  • พัฒนาข้อกำหนดการฝึกอบรมสำหรับผู้ใช้ปลายทาง
  • ระบุวิธีการจัดส่งการฝึกอบรม (ออนไลน์ห้องเรียน ฯลฯ )
  • พัฒนาสื่อการฝึกอบรม
  • สรุปเอกสารการฝึกอบรม
  • พัฒนากลไกการจัดส่งการฝึกอบรม
  • เอกสารประกอบการฝึกอบรมครบถ้วน

• Deployment

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

ตอนนี้ให้เราดูที่มุมมองโครงสร้างต้นไม้

มุมมองโครงสร้างต้นไม้

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

ประเภทของ WBS

WBS มีสองประเภท -

• Functional WBS- ใน WBS ที่ใช้งานได้ระบบจะเสียตามฟังก์ชั่นในแอพพลิเคชั่นที่จะพัฒนา สิ่งนี้มีประโยชน์ในการประมาณขนาดของระบบ

• Activity WBS- ในกิจกรรม WBS ระบบจะเสียตามกิจกรรมในระบบ กิจกรรมจะแบ่งออกเป็นงาน สิ่งนี้มีประโยชน์ในการประมาณค่าความพยายามและกำหนดเวลาในระบบ

ขนาดโดยประมาณ

Step 1 - เริ่มต้นด้วย WBS ที่ใช้งานได้

Step 2 - พิจารณาโหนดใบไม้

Step 3 - ใช้ Analogy หรือ Wideband Delphi เพื่อให้ได้ขนาดโดยประมาณ

ประมาณการความพยายาม

Step 1- ใช้เทคนิค Wideband Delphi เพื่อสร้าง WBS ขอแนะนำว่างานต่างๆไม่ควรเกิน 8 ชม. หากงานมีระยะเวลามากกว่าให้แยกงานออก

Step 2 - ใช้เทคนิค Wideband Delphi หรือการประมาณค่าสามจุดเพื่อให้ได้มาซึ่งค่าประมาณความพยายามสำหรับงาน

การตั้งเวลา

เมื่อ WBS พร้อมและทราบค่าประมาณขนาดและความพยายามแล้วคุณก็พร้อมสำหรับการกำหนดเวลางาน

ในขณะที่กำหนดเวลางานควรคำนึงถึงบางสิ่ง -

• Precedence - งานที่ต้องเกิดขึ้นก่อนงานอื่นกล่าวว่ามีความสำคัญเหนือกว่างานอื่น

• Concurrence - งานที่เกิดขึ้นพร้อมกันคืองานที่สามารถเกิดขึ้นได้ในเวลาเดียวกัน (ควบคู่กัน)

• Critical Path - ชุดงานตามลำดับเฉพาะซึ่งขึ้นอยู่กับวันที่เสร็จสิ้นโครงการ

  • โครงการทั้งหมดมีเส้นทางวิกฤต
  • การเร่งงานที่ไม่สำคัญไม่ได้ทำให้กำหนดการสั้นลงโดยตรง

วิธี Critical Path

Critical Path Method (CPM) คือกระบวนการในการกำหนดและเพิ่มประสิทธิภาพเส้นทางวิกฤต งานเส้นทางที่ไม่สำคัญสามารถเริ่มต้นก่อนหน้าหรือในภายหลังโดยไม่ส่งผลกระทบต่อวันที่เสร็จสมบูรณ์

โปรดทราบว่าเส้นทางวิกฤตอาจเปลี่ยนไปเป็นเส้นทางอื่นเมื่อคุณย่อเส้นทางปัจจุบัน ตัวอย่างเช่นสำหรับ WBS ในรูปก่อนหน้านี้เส้นทางวิกฤตจะเป็นดังนี้ -

เนื่องจากวันที่เสร็จสิ้นโครงการขึ้นอยู่กับชุดของงานตามลำดับงานเหล่านี้จึงเรียกว่างานสำคัญ

วันที่เสร็จสิ้นโครงการไม่ได้ขึ้นอยู่กับการฝึกอบรมเอกสารและการปรับใช้ งานดังกล่าวเรียกว่างานที่ไม่สำคัญ

ความสัมพันธ์ในการพึ่งพางาน

บางครั้งในขณะที่ตั้งเวลาคุณอาจต้องพิจารณาความสัมพันธ์แบบพึ่งพางาน ความสัมพันธ์ในการพึ่งพางานที่สำคัญ ได้แก่ -

• เสร็จสิ้นเพื่อเริ่มต้น (FS)
• เสร็จสิ้นเพื่อเสร็จสิ้น (FF)

เสร็จสิ้นเพื่อเริ่มต้น (FS)

ในความสัมพันธ์การพึ่งพางาน Finish-to-Start (FS) งาน B ไม่สามารถเริ่มทำงานได้จนกว่างาน A จะเสร็จสมบูรณ์

เสร็จสิ้นเพื่อเสร็จสิ้น (FF)

ในความสัมพันธ์การพึ่งพางาน Finish-to-Finish (FF) งาน B ไม่สามารถเสร็จสิ้นได้จนกว่างาน A จะเสร็จสมบูรณ์

แผนภูมิแกนต์

แผนภูมิแกนต์เป็นแผนภูมิแท่งประเภทหนึ่งซึ่งดัดแปลงโดย Karol Adamiecki ในปีพ. ศ. 2439 และเป็นอิสระโดย Henry Gantt ในช่วงทศวรรษที่ 1910 ซึ่งแสดงถึงกำหนดการของโครงการ แผนภูมิแกนต์แสดงวันที่เริ่มต้นและวันที่สิ้นสุดขององค์ประกอบเทอร์มินัลและองค์ประกอบสรุปของโครงการ

คุณสามารถใช้รูปแบบเค้าร่างในรูปที่ 2 ใน Microsoft Project เพื่อขอรับมุมมองแผนภูมิแกนต์

เหตุการณ์สำคัญ

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

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

เหตุการณ์สำคัญสามารถเชื่อมโยงกับเงื่อนไขสัญญา

ข้อดีของการประมาณโดยใช้ WBS

WBS ทำให้ขั้นตอนการประมาณโครงการง่ายขึ้นในระดับมาก มีข้อดีดังต่อไปนี้เหนือเทคนิคการประมาณอื่น ๆ -

• ใน WBS มีการระบุงานทั้งหมดที่ต้องทำในโครงการ ดังนั้นโดยการตรวจสอบ WBS กับผู้มีส่วนได้ส่วนเสียของโครงการคุณจะมีโอกาสน้อยที่จะละเว้นงานใด ๆ ที่จำเป็นในการส่งมอบโครงการที่ต้องการ

• WBS ส่งผลให้ประมาณการต้นทุนและกำหนดการถูกต้องมากขึ้น

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

• WBS เป็นพื้นฐานสำหรับการมอบหมายงาน เนื่องจากงานที่แม่นยำจะถูกจัดสรรให้กับสมาชิกในทีมโดยเฉพาะซึ่งจะต้องรับผิดชอบต่อความสำเร็จ

• WBS เปิดใช้งานการตรวจสอบและควบคุมในระดับงาน สิ่งนี้ช่วยให้คุณสามารถวัดความคืบหน้าและมั่นใจได้ว่าโครงการของคุณจะได้รับการส่งมอบตรงเวลา

การวางแผนการประมาณโป๊กเกอร์

Planning Poker เป็นเทคนิคที่ใช้ฉันทามติในการประมาณค่าซึ่งส่วนใหญ่ใช้ในการประมาณความพยายามหรือขนาดสัมพัทธ์ของเรื่องราวของผู้ใช้ใน Scrum

Planning Poker รวมเทคนิคการประมาณค่าสามแบบ - เทคนิค Wideband Delphi, Analogous Estimation และ Estimation โดยใช้ WBS

Planning Poker ได้รับการนิยามและตั้งชื่อครั้งแรกโดย James Grenning ในปี 2002 และต่อมาได้รับความนิยมจาก Mike Cohn ในหนังสือ "Agile Estimating and Planning" ซึ่งมีการค้าของ บริษัท ทำเครื่องหมายคำนี้

การวางแผนเทคนิคการประมาณโป๊กเกอร์

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

• Planning Poker เล่นด้วยสำรับไพ่ เมื่อใช้ลำดับฟีโบนักชีการ์ดจะมีตัวเลข - 1, 2, 3, 5, 8, 13, 21, 34 เป็นต้นตัวเลขเหล่านี้แสดงถึง "Story Points" ตัวประมาณแต่ละคนมีสำรับไพ่ ตัวเลขบนการ์ดควรมีขนาดใหญ่พอที่สมาชิกในทีมทุกคนจะมองเห็นได้เมื่อสมาชิกคนใดคนหนึ่งในทีมถือไพ่

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

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

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

• ทีมสามารถพูดคุยเกี่ยวกับเรื่องราวและประมาณการของพวกเขาได้อีกไม่กี่นาที

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

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

ประโยชน์ของการวางแผนการประมาณโป๊กเกอร์

การวางแผนโป๊กเกอร์รวมวิธีการประมาณสามวิธี -

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

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

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

ความพยายามในการทดสอบไม่ได้ขึ้นอยู่กับกรอบเวลาที่ชัดเจนใด ๆ ความพยายามจะดำเนินต่อไปจนกว่าจะมีการกำหนดเส้นเวลาที่กำหนดไว้ล่วงหน้าโดยไม่คำนึงว่าการทดสอบจะเสร็จสิ้น

ส่วนใหญ่เกิดจากความจริงที่ว่าตามอัตภาพ test effort estimation is a part of the development estimation. Only in the case of estimation techniques that use WBS, such as Wideband Delphi, Three-point Estimation, PERT, and WBS, you can obtain the values for the estimates of the testing activities.

If you have obtained the estimates as Function Points (FP), then as per Caper Jones,

Number of Test Cases = (Number of Function Points) × 1.2

Once you have the number of test cases, you can take productivity data from organizational database and arrive at the effort required for testing.

Percentage of Development Effort Method

Test effort required is a direct proportionate or percentage of the development effort. Development effort can be estimated using Lines of Code (LOC) or Function Points (FP). Then, the percentage of effort for testing is obtained from Organization Database. The percentage so obtained is used to arrive at the effort estimate for testing.

Estimating Testing Projects

Several organizations are now providing independent verification and validation services to their clients and that would mean the project activities would entirely be testing activities.

Estimating testing projects requires experience on varied projects for the software test life cycle. When you are estimating a testing project, consider −

• Team skills
• Domain Knowledge
• Complexity of the application
• Historical data
• Bug cycles for the project
• Resources availability
• Productivity variations
• System environment and downtime

Testing Estimation Techniques

The following testing estimation techniques are proven to be accurate and are widely used −

• PERT software testing estimation technique
• UCP Method
• WBS
• Wideband Delphi technique
• Function point/Testing point analysis
• Percentage distribution
• Experience-based testing estimation technique

PERT Software Testing Estimation Technique

PERT software testing estimation technique is based on statistical methods in which each testing task is broken down into sub-tasks and then three types of estimation are done on each sub-tasks.

The formula used by this technique is −

Test Estimate = (O + (4 × M) + E)/6

Where,

O = Optimistic estimate (best case scenario in which nothing goes wrong and all conditions are optimal).

M = Most likely estimate (most likely duration and there may be some problem but most of the things will go right).

L = Pessimistic estimate (worst case scenario where everything goes wrong).

Standard Deviation for the technique is calculated as −

Standard Deviation (SD) = (E − O)/6

Use-Case Point Method

UCP Method is based on the use cases where we calculate the unadjusted actor weights and unadjusted use case weights to determine the software testing estimation.

Use-case is a document which specifies different users, systems or other stakeholders interacting with the concerned application. They are named as “Actors”. The interactions accomplish some defined goals protecting the interest of all stakeholders through different behavior or flow termed as scenarios.

Step 1 − Count the no. of actors. Actors include positive, negative and exceptional.

Step 2 − Calculate unadjusted actor weights as

Unadjusted Actor Weights = Total no. of Actors

Step 3 − Count the number of use-cases.

Step 4 − Calculate unadjusted use-case weights as

Unadjusted Use-Case Weights = Total no. of Use-Cases

Step 5 − Calculate unadjusted use-case points as

Unadjusted Use-Case Points = (Unadjusted Actor Weights + Unadjusted Use-Case Weights)

Step 6 − Determine the technical/environmental factor (TEF). If unavailable, take it as 0.50.

Step 7 − Calculate adjusted use-case point as

Adjusted Use-Case Point = Unadjusted Use-Case Points × [0.65 + (0.01 × TEF]

Step 8 − Calculate total effort as

Total Effort = Adjusted Use-Case Point × 2

Work Breakdown Structure

Step 1 − Create WBS by breaking down the test project into small pieces.

Step 2 − Divide modules into sub-modules.

Step 3 Divide sub-modules further into functionalities.

Step 4 − Divide functionalities into sub-functionalities.

Step 5 − Review all the testing requirements to make sure they are added in WBS.

Step 6 − Figure out the number of tasks your team needs to complete.

Step 7 − Estimate the effort for each task.

Step 8 − Estimate the duration of each task.

Wideband Delphi Technique

In Wideband Delphi Method, WBS is distributed to a team comprising of 3-7 members for re-estimating the tasks. The final estimate is the result of the summarized estimates based on the team consensus.

This method speaks more on experience rather than any statistical formula. This method was popularized by Barry Boehm to emphasize on the group iteration to reach a consensus where the team visualized different aspects of the problems while estimating the test effort.

Function Point / Testing Point Analysis

FPs indicate the functionality of software application from the user's perspective and is used as a technique to estimate the size of a software project.

In testing, estimation is based on requirement specification document, or on a previously created prototype of the application. To calculate FP for a project, some major components are required. They are −

• Unadjusted Data Function Points − i) Internal Files, ii) External Interfaces

• Unadjusted Transaction Function Points − i) User Inputs, ii) User Outputs & iii) User Inquiries

• Capers Jones basic formula −

  Number of Test Cases = (Number of Function Points) × 1.2

• Total Actual Effort (TAE) −

  (Number of Test cases) × (Percentage of Development Effort /100)

Percentage Distribution

In this technique, all the phases of Software Development Life Cycle (SDLC) are assigned effort in %. This can be based on past data from similar projects. For example −

Phase	% of Effort
Project Management	7%
Requirements	9%
Design	16%
Coding	26%
Testing (all Test Phases)	27%
Documentation	9%
Installation and Training	6%

Next, % of effort for testing (all test phases) is further distributed for all Testing Phases −

All Testing Phases	% of Effort
Component Testing	16
Independent Testing	84
Total	100

Independent Testing	% of Effort
Integration Testing	24
System Testing	52
Acceptance Testing	24
Total	100

System Testing	% of Effort
Functional System Testing	65
Non-functional System Testing	35
Total	100

Test Planning and Design Architecture	50%
Review phase	50%

Experience-based Testing Estimation Technique

This technique is based on analogies and experts. The technique assumes that you already tested similar applications in previous projects and collected metrics from those projects. You also collected metrics from previous tests. Take inputs from subject matter experts who know the application (as well as testing) very well and use the metrics you have collected and arrive at the testing effort.