310414 software engineering
Download
1 / 51

310414 Software Engineering - PowerPoint PPT Presentation


  • 123 Views
  • Uploaded on

310414 Software Engineering. Cost Estimation. Cost Estimation. การวิเคราะห์ต้นทุน วิเคราะห์ก่อนโครงงานจะเริ่มต้น. [Jalote1991]. Why do we estimate?. เพื่อเอื้อโอกาสให้ทีมพัฒนาและลูกค้าได้มีโอกาสวิเคราะห์กำไรต้นทุน. [Jalote1991]. เป็นสิ่งสำคัญมากในการควบคุมการดำเนินโครงงาน

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' 310414 Software Engineering' - marli


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
310414 software engineering

310414Software Engineering

Cost Estimation

310414 - Lecture


Cost estimation
Cost Estimation

  • การวิเคราะห์ต้นทุน

  • วิเคราะห์ก่อนโครงงานจะเริ่มต้น

310414 - Lecture

[Jalote1991]


Why do we estimate
Why do we estimate?

  • เพื่อเอื้อโอกาสให้ทีมพัฒนาและลูกค้าได้มีโอกาสวิเคราะห์กำไรต้นทุน

310414 - Lecture

[Jalote1991]


Cost estimation for developers

เป็นสิ่งสำคัญมากในการควบคุมการดำเนินโครงงานเป็นสิ่งสำคัญมากในการควบคุมการดำเนินโครงงาน

ความคลาดเคลื่อนจากการประมาณสามารถใช้เป็นเกณฑ์ในการ

วัดสถานะของโครงงาน

วัดคุณภาพในการจัดการบุคคลากร

การประมาณต้นทุน จัดเป็นขั้นตอนหลักของการวางแผน

Cost Estimation for Developers

310414 - Lecture

[Jalote1991]


Uncertainties in cost estimation
Uncertainties in Cost Estimationเป็นสิ่งสำคัญมากในการควบคุมการดำเนินโครงงาน

  • ความไม่แน่นอนในการประมาณต้นทุน

ความคลาดเคลื่อนในการประมาณ

310414 - Lecture

[Jalote1991]


เทคนิคในการประเมินราคาซอฟต์แวร์เทคนิคในการประเมินราคาซอฟต์แวร์

  • ความแม่นยำในการประเมินราคามีความสำคัญดังนี้คือ

    • สามารถคิดกำไรที่ได้มาและระบบการเงินในบริษัท

    • สามารถคำนวณการใช้ทรัพยากร HW/SW ได้อย่างถูกต้อง

    • สามารถคำนวณราคาต่อโปรเจ็คย่อย ๆ ได้

  • ในการประเมินราคาเราควรที่จะบวกค่าความเที่ยงตรงไว้ + - 20%

310414 - Lecture


Estimation basics
Estimation Basicsเทคนิคในการประเมินราคาซอฟต์แวร์

  • Models

  • Metrics

  • Historical Data

310414 - Lecture


Estimation accuracy
Estimation Accuracyเทคนิคในการประเมินราคาซอฟต์แวร์

  • แม่นยำในการประมาณขนาด

  • แม่นยำในการประมาณกำลังบุคลากรและเวลาที่ใช้จากขนาด

  • แม่นยำในการวางแผนที่แสดงถึงความสามารถที่แท้จริงของทีมงาน

  • ความคงที่ของความต้องการของผลิตภัณฑ์ และสภาพแวดล้อมต่างๆ

310414 - Lecture


How not to estimate cost
HOW NOT TO ESTIMATE COSTเทคนิคในการประเมินราคาซอฟต์แวร์

มีองค์ประกอบภายนอกที่ทำให้การประมาณค่าไม่อาจทำได้หรือไม่ต้องทำ เช่น

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

  • โครงการซอฟต์แวร์ที่ต้องมีการประกวดราคาซึ่งเราทราบว่าคู่แข่งเสนอราคา 1 ล้านบาท เมื่อเป็นเช่นนี้เราต้องชนะการประกวดจึงเสนอราคาไป 9 แสนบาท

  • จริงๆแล้วโครงการใช้เวลา 1 ปีแต่ไม่สามารถบอกหัวหน้าได้หรือบอกเขาก็ไม่เชื่อจึงต้องกำหนดเวลาพัฒนาไว้ 10 เดือน

310414 - Lecture


Delphi method
DELPHI METHODเทคนิคในการประเมินราคาซอฟต์แวร์

  • ผู้บริหารหรือผู้มีอำนาจในองค์กรมีอิทธิพลต่อการประมาณราคาและเวลาในการพัฒนา

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

310414 - Lecture


An expected value
An Expected Valueเทคนิคในการประเมินราคาซอฟต์แวร์

  • ให้ผู้เชี่ยวชาญประมาณการค่าใช้จ่าย 3 ค่า คือ

    • ค่าแรกเป็นค่าดีที่สุดเช่นกรณีที่เสร็จก่อนเวลาเรียกว่า Optimistic Estimateแทนด้วยQ

    • ค่าที่สองเป็นค่าที่คิดว่าตรงความเป็นจริงหรือเป็นไปได้มากที่สุดเรียก Realistic Estimateแทนด้วย R

    • ค่าที่สาม เป็นค่าที่คิดว่าเลวร้ายที่สุดหรือแย่ที่สุดเท่าที่เป็นไปได้ เรียกว่า Pessimistic Estimateแทนด้วย S

  • แล้วใช้ความรู้เกี่ยวกับ beta distribution หาความสัมพันธ์

310414 - Lecture


An expected value1
An Expected Valueเทคนิคในการประเมินราคาซอฟต์แวร์

  • EV = (Q + 2R + P) / 4 หรือ

  • EV = (Q + 4R + P) / 6

    • Q = optimistic estimation

    • R = realistic estimation

    • P = prestimistic estimation

[Conger1994]

[Pressman1997]

aka a 3-point estimated value

310414 - Lecture


Estimation techniques 1
Estimation Techniques (1)เทคนิคในการประเมินราคาซอฟต์แวร์

  • Decomposition Techniques :

    • กระจายงานออกเป็นงานย่อยๆ เพื่อที่จะประมาณได้ โดยในงานย่อยนั้นอาจจะนำวิธีการคำนวณทางคณิตศาสตร์มาใช้ก็ได้

  • Empirical models (Algorithmic Cost Modeling) :

    • ใช้การคำนวณทางคณิตศาสตร์ หาความสัมพันธ์ระหว่างสิ่งที่ประมาณได้กับอีกสิ่งหนึ่ง

  • Based on last projects (Estimation by analogy)

310414 - Lecture

([Boehm1981] in [Sommerville1996]) and ([Pressman1997])


Estimation techniques 2
Estimation Techniques (2)เทคนิคในการประเมินราคาซอฟต์แวร์

  • Expert judgement

  • Parkinson’s Law :

    • ต้นทุนขึ้นกับทรัพยากรที่มีให้

  • Pricing to win

    • ต้นทุนที่ใช้ก็ต้นทุนที่มีให้

310414 - Lecture

([Pressman1997])


Decomposition techniques
Decomposition Techniquesเทคนิคในการประเมินราคาซอฟต์แวร์

  • Problem-Based Estimation

  • Process-Based Estimation

310414 - Lecture


Problem based decomposition
Problem-Based Decompositionเทคนิคในการประเมินราคาซอฟต์แวร์

  • แบ่งงานเป็นงานย่อยๆ โดยใช้ขั้นตอนตามปัญหา

  • ใช้ LOC และ FP

310414 - Lecture


An example of loc estm

Functionเทคนิคในการประเมินราคาซอฟต์แวร์

user interface and control facilities

two-dimensional geometric analysis

three-dimensional geometric analysis

estimated line of code

Estm. LOC

2300

5300

6800

33200

An Example of LOC Estm.

Using 3-point estimated values

310414 - Lecture


An example of fp estm
An Example of FP Estmเทคนิคในการประเมินราคาซอฟต์แวร์

info domain value

number of inputs

number of outputs

count-total

opt.

20

12

likely

24

15

pess.

30

22

ets.

24

16

w

4

5

FP

96

80

318

FP estm = count-total * factor

FP estm = 372

310414 - Lecture


Process based decomposition
Process-Based Decompositionเทคนิคในการประเมินราคาซอฟต์แวร์

  • แบ่งการประมาณเป็นงานย่อย ตามกระบวนการขั้นตอนพัฒนา

    • Planning

    • Analysis

    • Design

    • Code

    • Test

310414 - Lecture


Empirical models
Empirical Modelsเทคนิคในการประเมินราคาซอฟต์แวร์

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

  • Models :

    • Single-Variable Models

    • COCOMO Model

310414 - Lecture


Single variable model
Single-Variable Modelเทคนิคในการประเมินราคาซอฟต์แวร์

b

  • EFFORT = a * SIZE

  • EFFORT = a * SIZE + b

  • ฯลฯ

  • ค่าคงที่ a และ b คำนวณจากข้อมูลในอดีต

310414 - Lecture


Cocomo model

bเทคนิคในการประเมินราคาซอฟต์แวร์

  • E = a (KLOC) x EAF

  • D = c E

d

COCOMO Model

effort (person-month)

duration (month)

  • a b c และ d : constant ที่ขึ้นกับประเภทของ software

  • EAF : Effort Adjustment Factor

310414 - Lecture

[Boehm1981,1984] from [Jalote1991] and [Pressman1997]


Cocomo project types
COCOMO project typesเทคนิคในการประเมินราคาซอฟต์แวร์

  • Organic

    • a simple small application developed by a small team with good application experience.

  • Semidetached

    • โครงการที่มีขนาดหรือความซับซ้อนปลานกลาง

  • Embedded

    • โครงการพัฒนาซอฟต์แวร์ทีมีข้อจำกัดสูง.

310414 - Lecture


Organic
Organicเทคนิคในการประเมินราคาซอฟต์แวร์

  • ใช้ทีมขนาดเล็ก(1-3คน) ภายใต้ HW, SW และการประยุกต์ที่คุ้นเคย

  • บุคลากรที่เกี่ยวข้องกับการพัฒนามีประสบการณ์เป็นอย่างดีเกี่ยวกับซอฟต์แวร์ที่มีลักษณะคล้ายๆกันมาก่อน

  • กิจกรรมต่างๆเริ่มต้นได้อย่างรวดเร็ว

  • มีขนาดเล็ก

310414 - Lecture


Embedded
Embeddedเทคนิคในการประเมินราคาซอฟต์แวร์

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

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

  • เช่นซอฟต์แวร์ที่ใช้ควบคุมการขึ้นลงของเครื่องบิน ซอฟต์แวร์ควบคุมการยิงขีปนาวุธ

310414 - Lecture


Semi detached
Semi-detachedเทคนิคในการประเมินราคาซอฟต์แวร์

  • เป็นซอฟแวร์ที่มีขนาดและความยากปานกลาง

  • ทีมงานประกอบด้วยกลุ่มบุคคลที่มีทั้งประสบการณ์และไม่มีประสบการณ์

  • อยู่ระหว่างประเภท Organic และ Embeded

310414 - Lecture


Constants for different project types

Systemเทคนิคในการประเมินราคาซอฟต์แวร์

organic

semidetached

embedded

a

3.2

3.0

2.8

b

1.05

1.12

1.20

c

2.5

2.5

2.5

d

0.38

0.35

0.32

Constants fordifferent project types

310414 - Lecture


Effective adjustment factor
Effective Adjustment Factorเทคนิคในการประเมินราคาซอฟต์แวร์

  • Factor ที่คิดจากความต้องการในคุณสมบัติต่างๆ ของ software นั้น (cost driver attributes)

    • product attribute

    • computer attribute

    • personal attribute

    • project attribute

  • โดย Factor นี้จะมีค่ามากหรือน้อยขึ้นกับระดับของคุณลักษณะต่างๆ

310414 - Lecture


Product attributes
Product Attributesเทคนิคในการประเมินราคาซอฟต์แวร์

  • Reliability requirement

  • Database size

  • Product complexity

310414 - Lecture


Computer attributes
Computer attributesเทคนิคในการประเมินราคาซอฟต์แวร์

  • Execution time constraints

  • Storage constaints

  • Virtual machine volatility

  • Computer turnround time

310414 - Lecture


Personnel attributes
Personnel attributesเทคนิคในการประเมินราคาซอฟต์แวร์

  • Analyst capability

  • Virtual machine experience

  • Programmer capability

  • Programming language experience

  • Application experience

310414 - Lecture


Project attributes
Project attributesเทคนิคในการประเมินราคาซอฟต์แวร์

  • Modern programming practices

  • Software tools

  • Required development schedule

310414 - Lecture


Example
Exampleเทคนิคในการประเมินราคาซอฟต์แวร์

  • จากการประมาณขนาดโดยใช้ problem-based decomp. ได้ว่า

    • data entry 0.6 KLOC

    • data update 0.6 KLOC

    • query 0.8 KLOC

    • report gen. 1.0 KLOC

    • TOTAL 3.0 KLOC

  • cost driver attribute

    • Complexity high 1.15

    • Storage high 1.06

    • Experience low 1.13

    • Programmer capability low 1.17

310414 - Lecture


Example cont
Example (cont.)เทคนิคในการประเมินราคาซอฟต์แวร์

  • EAF = 1.15 * 1.06 * 1.13 * 1.17 = 1.61

  • Ei = 3.2 * (3 ^ 1.05) = 10.14 PM

  • E = 1.61 * 10.14 = 16.5 PM

    • ใช้กำลังบุคลากรประมาณ 16.5 คน-เดือน

  • D = 2.5 (16.5 ^ 0.38) = 7.23 M

    • ใช้เวลาประมาณ 7.23 เดือน

310414 - Lecture


Function point
การใช้ Function Pointเทคนิคในการประเมินราคาซอฟต์แวร์

  • วัดขนาดและความซับซ้อนโดยใช้เป็น Function ที่ต้องพัฒนา

  • ไม่ขึ้นอยู่กับภาษา เครื่องมือหรือ กรรมวิธี

  • สามารถประเมินใหม่ได้เนื่องจาก Function สามารถเปลี่ยนแปลงได้ง่าย

  • ไม่ค่อยเหมาะกับโปรแกรมทางด้านเทคนิคเท่าไหร่

310414 - Lecture


  • การคิดค่า เทคนิคในการประเมินราคาซอฟต์แวร์FP สามารถหาได้จากสมการดังนี้

  • FP = Total weighted count * (0.65 + (0.1* SUM(complexity adjustments)))

    • Total weighted count - ได้จากตารางที่กำหนดให้

    • complexity adjustments - ได้จากการตอบคำถาม 14 คำถาม

310414 - Lecture


Function point questions rating scale from 0 to 5
Function Point Questionsเทคนิคในการประเมินราคาซอฟต์แวร์( Rating Scale from 0 to 5)

1. Is reliable backup and recovery required?

2. Are data communications required?

3. Are any functions distributed?

4. Is performance critical?

5. Is operational environment volume high?

6. Is on-line data entry required?

7. Does on-lines data entry require multiple screens or operations?

310414 - Lecture


Function point questions rating scale from 0 to 51
Function Point Questionsเทคนิคในการประเมินราคาซอฟต์แวร์( Rating Scale from 0 to 5)

8. Is on-line files update used?

9. Are quires, screens, reports, or files complex?

10. Is processing complex?

11. Is code design for reuse?

12. Does implementation include conversion and installation?

13. Are multiple installations and/or multiple organizations involved?

14. Does application design facilitate user changes?

310414 - Lecture


Function point weight
Function Point Weightเทคนิคในการประเมินราคาซอฟต์แวร์

  • Simple = 22

  • Average = 30

  • Complex = 44

    FP = 22 * ( 0.65 + ( 0.1 * 36)) = 93.5

310414 - Lecture


Line of Code/FP Languageเทคนิคในการประเมินราคาซอฟต์แวร์

25 4GL

25 SQL

100 Cobol

  • Number of Lines of Code per Function Point * Number of Function Points = Total Line of Code

    เพราะฉะนั้น

    KLOC = 93.5*25 = 2.337 K

310414 - Lecture


  • นำไปคิดกับ เทคนิคในการประเมินราคาซอฟต์แวร์COCOMO Model

    • E = 2.4 x (2.33)1.05

    • E = 5.83 คน ต่อ เดือน

    • D = 2.5 x (5.83)0.38

    • D = 4.88เดือน

310414 - Lecture


ปัจจัยอื่นที่มีผลต่อราคาปัจจัยอื่นที่มีผลต่อราคา

  • ขนาดฐานข้อมูล

  • ความซับซ้อน

  • ข้อจำกัดด้านฮาร์ดแวร์

  • ความสามารถประสบการณ์ของโปรแกรมเมอร์

  • การใช้ Tool ในการพัฒนา

  • กำหนดการส่งงาน

  • ประสบการณ์ด้านการพัฒนา

310414 - Lecture


ปัจจัยความต้องการปัจจัยอื่นที่มีผลต่อราคา

- ความต้องการ

- ราคาของ

ปัจจัยข้อจำกัด

- การเงิน

- ทรัพยากร

กระบวนการประเมิน

ราคาซอฟต์แวร์

Effort

ปัจจัยอื่น ๆ

- ความเสี่ยง

- ฯลฯ

310414 - Lecture


ควรใช้โมเดลในการประเมินราคาหรือไม่ ?

  • ความไม่น่าเชื่อถือของโมเดล

  • ความต่างกันของการใช้ค่าคงที่

  • ดังนั้น

    • อาศัยการเปรียบเทียบจากโครงการเก่า ๆ ที่เคยทำ

    • ประสบการณ์ของผู้ประเมิน

310414 - Lecture


การประเมินราคา

  • การประเมินราคาไม่ได้ทำเพียงครั้งเดียวจบ

    • ระยะแรกก่อนการประมูล

    • ระยะสองทำหลังการประมูล

    • หัวหน้าทีมต้องพยายามประเมินราคาบ่อย ๆ เพื่อให้เหมาะสมกับราคาปัจจุบัน

310414 - Lecture


การประเมินราคาในทางปฏิบัติการประเมินราคาในทางปฏิบัติ

  • ดูความต้องการหลัก แล้วแบ่งให้เป็นความต้องการย่อย

  • งานที่ต้องทำ & ผลลัพธ์ที่ต้องได้

  • แปลงเป็นหน้าจอที่ต้องสร้าง

    • หน้าจอกรอกข้อมูล

    • หน้าจอสอบถามข้อมูล

    • หน้าจอรายงาน

    • หน้าจอบริหารระบบ

310414 - Lecture


การประเมินราคาในทางปฏิบัติการประเมินราคาในทางปฏิบัติ

  • คำนวณหน้าจอที่ต้องสร้างเป็น N หน้าจอ แล้วให้ B เป็นราคาต่อหน้าจอ

  • B ?

    • ค่าของ B อยู่ในช่วง 3,000-20,000

      ~ 5,000-13,000

310414 - Lecture


ตัวอย่างการประเมินราคาในทางปฏิบัติ

  • สมมุติประเมินว่าระบบต้องมีหน้าจอ 65 หน้าจอ รายงานที่ต้องทำ 15 รายงาน รวมเป็น 65 ชิ้นงาน

  • ใช้ราคากลางที่ 9,000 บาทต่อชิ้น ราคาเบื้องต้นน่าจะเป็น 585,000 บาท

  • โปรแกรมเมอร์หนึ่งคนเฉลี่ยทำได้ 6 หน้าจอต่อเดือน งานชิ้นนี้น่าจะใช้ 10 คน-เดือน

  • ระยะเวลางาน 5 เดือนเพราะฉะนั้นใช้โปรแกรมเมอร์ 10/5=2 คนช่วยกันทำงาน

310414 - Lecture


  • ทีมงานประกอบด้วยการประเมินราคาในทางปฏิบัติ

    • หัวหน้าโครงการ 1 คน ตลอดโครงการ (นั้นคือ 0.2 คนต่อเดือน = อาทิตย์ละครั้ง)

    • เลขานุการพิมพ์เอกสาร 2 คน (ใช้สองเดือนหลัง)

    • โปรแกรมเมอร์ 2 คน

    • หัวหน้าโครงการ 80,000 x 1 = 80,000

      เลขานุการ 20,000 x 2 = 40,000

      โปรแกรมเมอร์ 60,000 x 5 x 2 = 600,000

      720,000

310414 - Lecture


5การประเมินราคาในทางปฏิบัติ

Individual-Simple Program

Team- Large Complexity

จำนวนบรรทัดต่อปี ต่อคน

Team-Medium-Complexity

1000

ขนาดของโปรแกรม x 1000 บรรทัด

ตัวประกอบที่มีผลต่อโครงการ

  • ระดับโครงการ

    • เงินเดือนของโปรแกรมเมอร์

    • ระยะเวลาการพัฒนา

    • กรรมวิธีการพัฒนา

310414 - Lecture


  • ระดับองค์กร

    • คุณภาพของผู้บริหาร

    • โปรแกรมเมอร์

  • ระดับชิ้นงาน

    • เอกสาร

    • ภาษาโปรแกรมที่ใช้

    • ความซับซ้อนของงาน

310414 - Lecture


ad