Transcript Document 7886946

วิชา ITSC2301
วิศวกรรมซอฟต์แวร์ (Software Engineering)
วิศวกรรมระบบ (System Engineering)
การบริหารโครงการผลิตซอฟต์แวร์
การประมาณการซอฟต์แวร์ (Software Estimation)
วิศวกรรมระบบ (System Engineering)


วิศวกรรมระบบ ไม่ได้มงุ่ เน้นในเรือ่ งของซอฟต์แวร์อย่างเดียว แต่ให้
ความสาคัญกับส่วนประกอบอื่นๆ ด้วย
วิศวกรรมระบบ หมายถึง กระบวนการศึกษาและวิเคราะห์ของระบบทีม่ คี วาม
สลับซับซ้อน เพือ่ สนับสนุนการทางานในส่วนของวิศวกรรมซอฟต์แวร์ กิจกรรม
ของวิศวกรรมระบบ จะถูกดาเนินการไปพร้อมๆ กับกิจกรรมของวิศวกรรม
ซอฟต์แวร์
วิศวกรรมระบบ (System Engineering)
กิจกรรมของวิศวกรรมระบบ มีดงั นี้
 กาหนดวัตถุประสงค์ของระบบ
 กาหดนขอบเขตของระบบ
 แบ่งระบบออกเป็ นส่วนๆ ตามฟั งก์ชน
ั งานหรือคุณสมบัตริ ะบบ
 พิจารณาความสัมพันธ์ของส่วนประกอบต่างๆ ทีเ่ กีย
่ วข้องทัง้ หมด
 กาหนดความสัมพันธ์ของปั จจัยนาเข้า ประมวลผล และผลลัพธ์
วิศวกรรมระบบ (System Engineering)




พิจารณาปั จจัยทีม่ สี ว่ นเกีย่ วข้องในระบบ
กาหนดความต้องการในส่วนของการดาเนินการและฟั งก์ชนั งานทัง้ ระบบ
สร้างแบบจาลอง เพือ่ ใช้วเิ คราะห์และพัฒนาให้สอดคล้องกับแบบจาลอง
ซอฟต์แวร์ทส่ี ร้างขึน้
นาเสนอและแลกเปลีย่ นข้อคิดเห็นกับผูใ้ ช้ระบบ
วิศวกรรมระบบ (System Engineering)
กระบวนการวิศวกรรระบบ ประกอบไปด้วยขัน้ ตอน 7 เฟส ดังนี้







การกาหนดความต้องการ (Requirement Definition)
การออกแบบระบบ (System Design)
การพัฒนาระบบย่อย (Sub-system Development)
การผนวกรวมระบบ (System Integration)
การติดตัง้ ระบบ (System Installation)
การเปลีย่ นแปลงระบบ (System Evolution)
การปลดระวางระบบ (System Decommission)
วิศวกรรมระบบ (System Engineering)
วิศวกรรมระบบ (System Engineering)

การกาหนดความต้องการ (Requirement Definition)


เพือ่ กาหนดนิยามความต้องการของระบบให้ชดั เจน กาหนดหน้าทีว่ า่ ระบบควรจะทาอะไร
ได้บา้ ง เป็ นเพียงข้อกาหนดเบือ้ งต้น
การออกแบบระบบ (System Design)

เป็ นการกาหนดรายละเอียดของฟั งก์ชนั ในแต่ละส่วนประกอบของระบบ มีดงั นี้
 แบ่งส่วนความต้องการ
 กาหนดระบบย่อย
 กาหนดความต้องการในแต่ละระบบย่อย
 กาหนดฟั งก์ชน
ั ของแต่ละระบบย่อย
 กาหนดส่วนประสานของระบบย่อย
วิศวกรรมระบบ (System Engineering)

การออกแบบระบบ (System Design)
วิศวกรรมระบบ (System Engineering)

การพัฒนาระบบย่อย (Sub-system Development)
 เป็ นการนาเอาระบบย่อยทีถ
่ ูกกาหนดรายละเอียดไว้ในระยะออกแบบ มาสร้างด้วย
กระบวนการทีเ่ หมาะสม

การผนวกรวมระบบ (System Integration)
 ระบบย่อยทีพ
่ ฒ
ั นาเสร็จแล้ว จะนามาผนวกรวมเข้าด้วยกันจนเป็ นระบบที่สมบูรณ์
หลังจากรวมระบบแล้ว ทีมงานต้องทาการทดสอบการทางานของระบบอีกครัง้
วิศวกรรมระบบ (System Engineering)

การติดตัง้ ระบบ (System Installation)
 นาระบบทีพ
่ ฒ
ั นาเรียบร้อยแล้วมาติดตัง้ เพือ่ ใช้งาน

การเปลีย่ นแปลงระบบ (System Evolution)
 ในช่วงการใช้งานระบบ อาจเกิดการเปลีย
่ นแปลงต่างๆ อาจต้องการการแก้ไข
ข้อผิดพลาดต่างๆ

การปลดระวางระบบ (System Decommission)
 หมายถึง
การเลิกใช้งานหลังจากพบว่าระบบไม่สามารถใช้ประโยชน์ได้อกี ต่อไป
การจาลองระบบ (System Modeling)

แบบจาลอง แฮทลีย-์ เพอร์ไบ (HatLey-Pirbhai Modeling)
 ข้อมูลเข้า
(Input)
 ประมวลผล (Processing)
 ข้อมูลออก (Output)
 การประมวลผลการต่อประสาน (User Interface Processing)
 การบารุงรักษา และทดสอบตัวเอง (Maintenance and self –test Processing)
แบบจาลอง แฮทลีย-์ เพอร์ไบ (HatLey-Pirbhai Modeling)
การสร้างแบบจาลองระบบด้วย UML


UML มีแผนภาพ (Diagram) หลายๆ แบบให้เลือกใช้เพือ่ การวิเคราะห์และ
การออกแบบในระดับระบบ และระดับซอฟต์แวร์
UML คือ โมเดลมาตรฐานทีใ่ ช้หลักการออกแบบ OOP(Object oriented
programming)
การสร้างแบบจาลองระบบด้วย UML

Class Diagram

Object Diagram

Component Diagram

Deployment Diagram

Use Case Diagram

Sequence Diagram

Collaboration Diagram

StateTransition Diagram

Activity Diagram
Structural Diagrams
Behavioral Diagrams
Use Case
Use Case
Diagrams
Sequence
Diagrams
Diagrams
Scenario
Scenario
Diagrams
Collaboration
Diagrams
Diagrams
Scenario
Scenario
Diagrams
Statechart
Diagrams
Diagrams
Use Case
Use Case
Diagrams
Use Case
Diagrams
Diagrams
State
State
Diagrams
Class
Diagrams
Diagrams
State
State
Diagrams
Object
Diagrams
Diagrams
State
State
Diagrams
Component
Diagrams
Diagrams
Models
Component
Component
Diagrams
Deployment
Diagrams
Activity
Diagrams
Diagrams
การสร้างแบบจาลองระบบด้วย UML

5 มุมมองหลักของ UML
 Use-case view : หน้ าที่ การทางานของระบบซอฟต์แวร์ โดยพิจารณาจาก
มุมมองของผูใ้ ช้ภายนอก หรือ ระบบภายนอก
 use-case diagram
 Logical view : หน้าที่การทางานของระบบมีโครงสร้างอย่างไร มองในรูป
ของ static structure และ dynamic behavior
 class diagram, object diagram, state, sequence, collaboration,
activity diagrams
การสร้างแบบจาลองระบบด้วย UML
Component view : องค์ประกอบย่อยในการ implement ที่ประกอบเป็ นระบบ และ
dependency ระหว่างองค์ประกอบเหล่านัน้
 component diagram
 Concurrency view: การแบ่งแยก process และ processors โดยพิจารณาทัง้
communication และ synchronization
 dynamic diagrams (state, sequence, collaboration activity)
 implementation diagrams(component และ deployment)
 Deployment view : โครงสร้างทางกายภาพเกี่ยวกับ การติดตั้ง และใช้งานระบบ
 deployment diagram

การสร้างแบบจาลองระบบด้วย UML

Use case Diagram
ในการพัฒนาระบบงานใดๆ นัน้ การเก็บรวบรวมความต้องการของผูใ้ ช้ม ี
ความสาคัญมาก และจะทาในระยะแรกๆ ของการพัฒนาระบบงานเสมอ Use case
diagram เป็ น Diagram ทีท่ าหน้าที่ Capture requirement
 เป็ นเทคนิคในการสร้างแบบจาลองเพือ
่ ใช้อธิบายหน้าทีข่ องระบบใหม่ หรือระบบปั จจุบนั
 กระบวนการสร้าง Use
case เป็ นแบบ Iteration
 ความต้องการของระบบจะได้จาก ลูกค้า/ผูใ้ ช้ + ผูพ
้ ฒ
ั นาระบบ
 องค์ประกอบจะมี Use case, Actor, Use case Relation และ System
Use Case Diagram
deposit
withdraw
customer
transfer
teller
statement
add
interest
Class Diagram

Class Diagram ประกอยด้วย Class และความสัมพันธ์ระหว่าง Class เช่น
Dependency, Generalization, Association เป็ นต้น Class Diagram
สามารถแสดงรายละเอียดว่ามี Method และ Attribute อย่างไร
Class Diagram
Object Diagram

Object Diagram ประกอบด้วย Object และ Relation ระหว่าง Object โดย
แต่ละ Object จะแสดง Instance ของแต่ละ class ทีม่ ใี นระบบ และ
ความสัมพันธ์ระหว่าง Class เช่น Dependency, Generalization หรือ
Association ซึง่ มีลกั ษณะเช่นเดียวกับ Class Diagram
Object Diagram
Sequence Diagram


Sequence Diagram จะแสดงลาดับการทางานของระบบ โดยมี Object และ
เวลาเป็ นตัวกาหนดลาดับของงาน และเน้นไปที่ instant ของ Oject
Sequence Diagram เป็ น Diagram ซึง่ แสดงปฏิสมั พันธ์(Interaction) ระหว่าง
Object ตามลาดับของเหตุการณ์ทเ่ี กิดขึน้ ณ เวลาทีก่ าหนด message ทีเ่ กิดขึน้
ระหว่าง class จะสามารถนาไปสูก่ ารสร้าง method ใน class ทีเ่ กีย่ วข้องได้
Sequence Diagram
Collaboration Diagram

Collaboration Diagram แสดงลาดับการทางานของ วัตถุ ผูเ้ กีย่ วข้อง และ
กิจกรรม โดยลาดับการทางานไม่ขน้ึ กับเวลา เพราะการแสดงความสัมพันธ์
ของ Object กับเวลาเป็ นหน้าทีข่ อง Sequence Diagram
Collaboration Diagram
State Diagram

State Diagram ประกอบด้วย State ต่างๆ ของ Object และเหตุการณ์
ต่างๆ ทีท่ าให้สถานะของ Object เปลีย่ นและการกระทาทีเ่ กิดขึน้ เมือ่
สถานะของระบบเปลีย่ นไป สามารถบอกสถานะของ Object ได้ โดยจะ
ให้ความสนใจว่า ณ เวลาใดๆ Object นัน้ มี status เป็ นแบบใด
State Diagram
Activity Diagram

Activities Diagram แสดงลาดับ กิจกรรมของการทางาน(Work Flow)
สามารถแสดงทางเลือกทีเ่ กิดขึน้ ได้ Activity Diagram จะแสดงขัน้ ตอนการ
ทางานในการปฏิบตั กิ าร โดยประกอบไปด้วยสถานะต่างๆ ทีเ่ กิดขึน้ ระหว่าง
การทางาน และผลจากการทางานในขัน้ ตอนต่าง ๆ
Activity Diagram
Component diagram

Component Diagram เป็ น Diagram ซึง่ แสดงโครงสร้างทางกายภาพ
ของ Software โดยจะประกอบด้วยองค์ประกอบซึง่ อยูใ่ นรูปต่างๆ เช่น
Binary, text และ executeable ภายใน Component Diagram ก็จะมี
ความสัมพันธ์แสดงอยูเ่ ช่นเดียวกับ Class Diagram, Object Diagram
Component diagram
Deployment diagram

Deployment Diagram เป็ นสิง่ ทีส่ ามารถทาการแสดงระบบ
สถาปั ตยกรรมของ Hardware/Software ตลอดจนความสัมพันธ์
ระหว่าง hardware/software
Deployment diagram
การบริหารโครงการผลิตซอฟต์แวร์

การบริหารโครงการ (Project management)


การประยุกต์ใช้องค์ความรู้ ทักษะ เครื่องมือ และเทคนิค เพื่อดาเนินกิจกรรมตาม
ความต้องการของโครงการให้บรรลุวตั ถุประสงค์ที่กาหนดไว้
วงจรชีวิตของโครงการ
โครงการทุกประเภท จะมีทงั ้ หมด 4 ระยะ ได้แก่
 ระยะเริ่มต้นโครงการ (Project Initiation)
 ระยะวางแผนโครงการ (Project Planning)
 ระยะดาเนินโครงการ (Project Execution)
 ระยะปิดโครงการ (Project Closing)
การบริหารโครงการผลิตซอฟต์แวร์

การจัดตารางงานโครงการ
 Gantt Chart
 PERT/CPM
Gantt Chart
PERT/CPM


มีการแสดงงานในลักษณะของ Node และความเกีย่ วเนื่อง (Dependency)
ของงานแต่ละอันทีเ่ กิดขึน้ อย่างชัดเจน
จุดเด่นของ PERT/CRM คือ การคานวณหาเส้นทางวิกฤติในการดาเนิน
กิจกรรม ทาให้ผบู้ ริหารโครงการคานวณหาเวลาได้หลายลักษณะ เช่น เวลา
ทีเ่ ร็วทีส่ ดุ ของแต่ละกิจกรรม (Time Earliest : TE) เวลาทีช่ า้ ทีส่ ดุ ของแต่ละ
กิจกรรม (Time Latest : TL) เป็ นต้น
PERT/CPM

เวลาทีเ่ ร็วทีส่ ดุ ของแต่ละกิจกรรม (Time Earliest : TE)
 คานวณจากซ้ายมาขวา

คือ บวกค่าเพิม่ จาด้านซ้ายมาด้านขวา
เวลาทีช่ า้ ทีส่ ดุ ของแต่ละกิจกรรม (Time Latest : TL)
 เวลาทีช
่ า้ ทีส่ ุดทีง่ านนัน้ ยังสามารถทาเสร็จได้โดยไม่กระทบแผนงาน
นัน้ คือ ลดค่าทีเ่ กีย่ วข้องจากด้านขวามาซ้าย โดยพิจารณาจากงาน
สุดท้ายก่อน
PERT/CPM
การประมาณการซอฟต์แวร์ (Software Estimation)

การประมาณการซอฟต์แวร์ เป็ นส่วนทีส่ าคัญในการวางแผนงาน เนื่องจาก
แผนงานนัน้ จะอยูบ่ นพืน้ ฐานของสิง่ ทีต่ อ้ งการทาการจัดสร้างหรือพัฒนา โดย
ในส่วนของซอฟต์แวร์นนั ้ มุมมองหลักทีม่ องถึง คือเรือ่ งของขนาด (Size)
ค่าใช้จา่ ย (Cost) บุคลากรทีใ่ ช้ในการพัฒนา (Effort)
Size Estimation

สิง่ แรกทีจ่ ะต้องทาก่อนการเริม่ ต้น
การประมาณการ คือ การวัด แยก
ลักษณะการวัดออกเป็ น 2 เชิง คือ
การวัดในเชิงปริมาณ (Software
Quantitative) และการวัดเชิงคุณภาพ
(Software Qualitative)
Size Estimation

กรรมวิธที ใ่ี ช้ในการวัดขนาดของซอฟต์แวร์ มี 2 ลักษณะ คือ
 Line
of Code (LOC) Count
 Function Point (FP)
Line of Code (LOC) Count





นับเฉพาะบรรทัดทีม่ กี ารจัดส่งเป็ น Source Code ไม่นบั รวมส่วนของการ
ทดสอบ (Test Driver) หรือส่วนงานทีร่ องรับการทางานอื่นๆ
นับเฉพาะบรรทัดทีพ่ ฒ
ั นาโดยบุคลากร ไม่นบั รวมสิง่ ทีร่ ะบบงานสามารถ
Generate ได้อตั โนมัติ
ถือว่าหนึ่งคาสัง่ คือ หนึ่ง Line of Code <LOC>
นับส่วนของการประกาศค่า (Declaration) เป็ นส่วนของ Instruction
ไม่นบั ส่วนของการขยายความ หรือ Comment
Function Point (FP)



ปั จจุบนั การนับขนาดของโปรแกรมด้วยการนับบรรทัดนัน้ ไม่สามารถให้ผล
การวัดในเชิงผลสัมฤทธิของโปรแกรมได้
อย่างชัดเจน การนาวิธกี ารนับด้วย
์
ฟั งก์ชนพอยต์
ั่
เข้ามาใช้นนั ้ จึงได้รบั ความสนใจ
การวัดด้วยฟั งก์ชนั พอยต์ จะมุง่ เน้นทีก่ ารวัดด้วยฟั งก์ชนั หรือการวัดโดย
ผ่านมุมมองความต้องการของซอฟต์แวร์
Allan Albrecht [1] John Gaffney, Jr [2] ได้ออกแบบ FPs ทีใ่ ช้วดั ฟั งก์ชนั ่
พอยต์ FPs เป็ นผลรวมของขนาด ข้อมูลเข้า, ข้อมูลออก, ข้อมูลความ
ต้องการ, แฟ้ มข้อมูล และส่วนของโปรแกรมทีใ่ ช้ในการติดต่อกับลูกค้า
Function Point (FP)
กระบวนการนับฟั งก์ชนั พอยต์ มีลกั ษณะดังนี้
ขัน้ ที่ 1 นา Requirement ที่เก็บรวบรวมไว้มาทาการแบ่งฟั งก์ชนั พอยต์
ขัน้ ที่ 2 ประเมินความซับซ้อนของฟังก์ชนั
ขัน้ ที่ 3 เปรียบเทียบความซับซ้อน เพื่อให้ได้ระดับความซับซ้อน เพื่อคานวณฟั งก์ชนั
พอยต์ที่ยงั ไม่ได้ปรับค่า (Unadjusted Function Point : UFP)
ขัน้ ที่ 4 คานวณค่าตัวแปรปรับค่า (Value Adjustment Factor) ตามลักษณะของโครงการ
ขัน้ ที่ 5 คานวณจานวนฟังก์ชนั พอยต์ที่ผา่ นการปรับค่า (Adjusted Function Point : AFP)
ขัน้ ที่ 6 ฟังก์ชนั พอยต์ที่ผา่ นการปรับค่า สามารถนาไปคานวณเป็ น LOC ได้

Function Point (FP)

ประเภทของฟั งก์ชนั พอยต์ สามารถแบ่งได้ 5 ลักษณะหลัก คือ
 External Input (EI)
 External Output (EO)
 External Inquiry (EQ)
 Internal Logical Files (ILF)
 External Interface Files (EIF)
Function Point (FP)
Function Point (FP)

แต่ละฟั งก์ชนั พอยต์นนั ้ มีองค์ประกอบต่างๆ ในฟั งก์ชนั แต่ละประเภท
ซึง่ จะแตกต่างกันได้ เช่น
 การเกีย
่ วข้องกับองค์ประกอบข้อมูล
(Data Element : DET)
 เป็ นข้อมูล เปรียบเสมือนฟิ ลด์ขอ้ มูลทีส่ นใจในแต่ละฟิ ลด์
 เรคคอร์คข้อมูล
(Record Element : RET)
 กลุม
่ ของข้อมูล หรือกลุม่ ย่อยของ
DET หรือการนับประเภทของเรคคอร์ดข้อมูล
ทีเ่ กีย่ วข้องสัมพันธ์กบั ฟั งก์ชนั ทีส่ นใจ
 ประเภทไฟล์
(File Type of Record : FTR)
คานวณ Function Point (FP)
FP = UFP x VAF
จานวนของฟั งก์ชนั หาได้จาก FP ทีย่ งั ไม่ได้ถกู ปรับแต่ง (Unadjusted Function
Point : UFP) คูณกับค่าปั จจัยคุณลักษณะของระบบ (Value Adjustment Factor
: VAF)
VAF = 0.65 + [0.01 x Total DI]
DI : Degree of Influence
UAF

จะเห็นว่าการกาหนดฟั งก์ชนั โดยแยกออกเป็ น 5 ประเภทหลัก ตามลักษณะ
ของการทางานนัน้ จะช่วยทาให้การประเมินลักษณะความต้องการของ
ซอฟต์แวร์ การพิจารณาองค์ประกอบทีเ่ กีย่ วข้องกับประเภทของแต่ละ
ฟั งก์ชนั พอยต์นนั ้ จะทาให้สามารถพิจารณาความซับซ้อนของฟั งก์ชนั พอยต์
ได้อย่างเป็ นรูปธรรมมากขึน้ โดยพิจารณาจากตาราง
UAF
UAF

จากตารางข้างบน จะได้ระดับความซับซ้อนของการทางาน จากนัน้ นาค่า
ความซับซ้อนทีเ่ ป็ นค่าเฉลีย่ มาทาการคานวณค่า Complexity weight ตาม
ตารางนี้
VAF
การประเมิน VAF นัน้ จะประเมินค่าของ 14 ปั จจัย ดังนี้
1. การติดต่อสือ่ สารข้อมูล (Data Communication)
2. การประมวลผลข้อมูลแบบกระจาย (Distributed Data Processing)
3. ประสิทธิภาพของระบบ (Performance)
4. การแก้ไขค่าของระบบ (Configuration)
5. ปริมาณรายการข้อมูล (Transaction)
6. การป้ อนข้อมูลเข้าสูร่ ะบบแบบออนไลน์ (Online Data Entry)
VAF
7.
8.
9.
10.
11.
12.
13.
ประสิทธิภาพการใช้งานของผูใ้ ช้ (End user Efficiency)
การปรับปรุงข้อมูลแบบออนไลน์ (Online Update)
ความซับซ้อนของการประมวลผล (Complex Processing)
การนาไปใช้ซ้าได้ (Reusability)
ความง่ายในการติดตัง้ (Installation Ease)
ความง่ายในการดาเนินงาน (Operational Ease)
การใช้งานได้หลายไซต์ (Multiple Sites)
VAF
14. รองรับการเปลีย่ นแปลงความต้องการของผูใ้ ช้ (Change Requirement)
โดยการประเมินนัน้ แบ่งออกเป็ น 5 ระดับตาม Degree of Influence (DI)
0 Not Present
ไม่มผี ลเกีย่ วข้องกับตัวแปรนัน้ ๆ
1 Incidental Influence มีความเกีย่ วข้องกับตัวแปรนัน้ ๆ โดยมีเกิดขึน้ ใน
ระบบงาน ไม่กระทบต่อการทางาน
2 Moderate Influence มีความเกีย่ วข้องกับตัวแปรนัน้ ๆ โดยมีเกิดขึน้ ใน
ระบบงาน กระทบต่อการทางาน โดยทาให้การ
ทางานซับซ้อนขึน้ บ้างเล็กน้อย
VAF
3
4
5
มีความเกี่ยวข้องกับตัวแปรนัน้ ๆ โดยมีเกิดขึน้ ใน
ระบบงาน กระทบต่อการทางาน โดยทาให้การ
ทางานซับซ้อนขึน้
Significant Influence มีความเกี่ยวข้องกับตัวแปรนัน้ ๆ โดยมีเกิดขึน้ ใน
ระบบงาน กระทบต่อการทางาน โดยทาให้การ
ทางานซับซ้อนค่อนข้างมาก
Strong Influence
มีความเกี่ยวข้องกับตัวแปรนัน้ ๆ โดยมีเกิดขึน้ ใน
ระบบงาน กระทบต่อการทางาน โดยทาให้การ
ทางานซับซ้อนมาก
Average Influence
ตารางเปรียบเทียบค่า FP เพือ่ แปลงไปเป็ น LOC
ตัวอย่างการคานวณค่าฟั งก์ชนั พอยต์

จาก Use case Diagram ดังรูป จะ
ทาการแยกประเภทของ use case
ตามฟั งก์ชนั พอยต์
ตัวอย่าง
ตัวอย่าง

ทาการเปรียบเทียบค่าของ Value
Adjustment Factors : VAF
ตัวอย่าง
VAF
FP
= 0.65 + [0.01 x 17]
= 0.82
= UFP x VAF
= 23 x 0.82
= 18.86 FP
ถ้าหากจัดทาซอฟต์แวร์โดยใช้ภาษาจาวา จะได้ค่า LOC
= 18.86 x 53 = 999.58
~1000 LOC
การประมาณการบุคลากร

Productivity : ประสิทธิผลในการผลิตงาน
Productivity = Output Size (LOC or Function Point)
Effort (Man-Month)
COCOMO


Boehm B.W. ได้พฒ
ั นา COCOMO Model (Constructive Cost Model)
เพือ่ วัด Effort ในการพัฒนาซอฟต์แวร์ทค่ี ดิ เป็ นหน่วย คน-เดือน (personmonth) ทีป่ ระมาณจากขนาดของโปรแกรม โดยนับจานวนบรรทัดของ
โปรแกรมต้นฉบับเป็ นหลัก
แบบจาลอง COCOMO ถูกพัฒนาเป็ นเวอร์ชนั ่ 2 คือ COCOMO II แบ่ง
แบบจาลองออกเป็ น 3 ชนิด เพือ่ ใช้ประมาณการในระยะต่างๆ ของ
กระบวนการพัฒนาซอฟต์แวร์
COCOMO II

Application Composition Model


Early Design Model


เหมาะกับการผลิตซอฟต์แวร์ด้วยแนวทางคอมโพเน้ นท์ โดยแต่ละคอมโพเน้ นท์สามารถอธิบาย
แทนด้วย Object Point ได้ ขนาดของซอฟต์แวร์นับเป็ น Object Point
ใช้ประมาณการในระยะก่อนการออกแบบซอฟต์แวร์ แต่หลังจากการกาหนดความความต้องการ
แล้ว ใช้ค่า FP แทนขนาดของซอฟต์แวร์
Post-Architecture Model

ใช้ประมาณการในระยะหลังการออกแบบซอฟต์แวร์ เป็ นการประมาณการอีกครัง้ เพื่อความถูกต้อง
ของค่าประมาณการที่ได้
COCOMO II

โมเดลการคานวณของ COCOMO II
PM = A x SizeE x EM + PMauto
PM คือ Effort มีหน่ วยเป็ น Person-Months (PM)
A ค่าคงทีท่ ไ่ี ด้จากการรวบรวมข้อมูลใน 161 โครงการ โดย A = 2.94
E คือ Economics of Scale ซึง่ เป็ นผลทีข่ นาดของซอฟต์แวร์สมั พันธ์กบั ขนาดของโครงการ โดย E = B + 0.01 *  Scale
Factors
B Scaling Base-exponent สาหรับคานวณ Effort
EM คือ Effort Multipliers เป็ นค่าทีไ่ ด้จากการคานวณ Cost Driver ทีเ่ กีย่ วกับโครงการ ทีส่ ง่ ผลต่อ Effort ในการพัฒนาซอฟต์แวร์
PMauto ค่าของ Effort ทีไ่ ด้จากการแปลงอัตโนมัติ ซึง่ จะเกิดเมือ่ มีการ Reuse Code โดยค่านัน้ จะไม่มผี ลต่อการพัฒนา แต่
เนื่องจากมีผลต่อค่าใช้จ่าย ถ้าเป็ นการพัฒนาซอฟต์แวร์ใหม่ ค่า PMauto จะเป็ น 0
COCOMO II

ระยะเวลาที่ใช้ในการพัฒนาซอฟต์แวร์มสี ูตรดังนี้
TDEV = [ C x (PM)F ] x SCED%
100
C
F
D
SCED
คือ Schedule Coefficient ทีใ่ ช้มาคานวณ โดย C = 3.67
คือ Scaling Exponent สาหรับระยะเวลา โดย F = [ D + 0.2 (E-B) ]
Scaling Base-exponent สาหรับ ระยะเวลา โดย D = 0.28
คือ ความรีบเร่งของเวลาเมือ่ เปรียบเทียบกับการพัฒนาปกติ