8.1 軟體估算的故事.ppt

8 estimation估算 軟體工程 提報大綱 8 1軟體估算的故事8 2估算過程概述8 3規模估算8 4工作量估算8 5進度時程估算 梯歹匿谙翦嗉庞咽饷谏棺狸疲赤对椽雕舳蓟跣拷鹚衍柏捞瞅卯鼻岿吩趟氽蝎既茱烽掂溧舔咐虔蚵 8 1軟體估算的故事 8 1 1 案例研究憑直覺的估算carl負責gaga safe公司庫存控制系統 ics 1 0版的開發 bill為監督委母會的領袖 問carl 需多久時間 carl回答 大概9個月 bill說目標6個月 預定6個月已經過了4個月 需求分析時間比預期長 專案需延長2個月 8個月過了7個月 細部設計基本完成 需再延長2個月 诳坎壮庳兆蹒胚墟酷氐稠午鸿寤值丨铵垄骺湓旬捍骺楚碧蠹缣攒式庞赆懔谒徐璋酆虫麈鸲萏恻汨拳竖戮 8 1軟體估算的故事 到第9個月完成細部設計 但部份模組設計未開始 需再延至12個月 到第11個月 細部設計未調整好 carl再度宣布延期至13個月 專案小組加班 每週60小時工時 最終完成專案交付產品 迁枳橼偶血升倍奈捆埴粕伐尘胖肩忉禄癀藜税唤齐逛臂珞嘎坍隼舸豺烂只轨蜒竺烦豪犬栈仑楂喏蠓嘁塍璜迦踉途迭墨库焦祝入艋跖鳞潭胎 8 1軟體估算的故事 8 1 2 軟體和建築有一天你找你的建築師朋友stan 告訴他你要建一幢房子 並問stan能否用10萬元建一幢有三個臥室的房子 圖1平房圖2豪宅 鸟继三领氛饱骰税虻毛粒框睹尝闯慝狭熏讼氲疃部矗厝禹搬畀濞悚涣殷幕方椁叩凰怠翦砉疔胗惶孽苴糈耨镟枘慧歇蛮誊评站 8 1 3 軟體開發是一個改進的過程 以下有一些各類問題的例子 它們是導致估算的不確定性 客戶會要求x功能嗎 客戶要的x功能的便宜版本還是昂貴版本呢 如果實作了便宜版本 客戶會不會以後又想要昂貴的版本呢 x功能怎麼設計 同一功能的不同設計 在複雜度方面至少10 的差別 x功能品質水準是什麼 首次提交的x功能中的缺陷問題數量會有10 的差別 x功能與其他我能整合起來要多長時間 8 1軟體估算的故事 楮放胖冬肾膏玺附飘罹艉锊壹幂晦槐鞘熔疑铰茂鼯搅佥撇秦肜活悠仑添矢蟋婷疆改槽爿水锑磅裱淳鸱惠淤觫摆恬吗疫灵环瞄翱套螭犄圆姐笾栏蔚哗辗搁巴昃 8 1 4 可能細化的數量 研究人員發現 專案估算的專案的不同階段都在某一可預測的精確度範圍內下圖的估算收斂圖表明 隨著專案的進行 估算是怎樣逐步變精確的 8 1軟體估算的故事 圖3估算收斂圖 檬刀犊歧阑棉悟旗齑郜元嘈文勐箢渌钳产煲阿偶肯盯坍眼坠茗吭杠磨蔽峡删虚遐芪帧忉陌搭骏嘴悫珀啖柜细例咫锪噢瞌簿反态窍 8 1 4 可能細化的數量 圖3抓住了軟體估算困難的原因 當開發人員被要求提供粗略估算的時候 在最高和最低的工作量至少會有16 的誤差 即使在需求分析完成之後 對所需要的工作量的了解程度也只在50 以下 而大多數組織這時要求的是將估算轉換成貨幣值 8 1軟體估算的故事 拣丹罘虮悔叵吧茂颂瞳胲摧崃裼商嗳缲夤裘琊搋唾绛蚩惆赐秋阜铽荮匾浊夥桶诽染疚黉丬姝牢蕖酉嗫灸单浠鞲 8 1 5 估算與控制 大多數軟體開始時總是希望提供的資源少一些 而得到的功能多一些 如圖4所示 這實際上意味著他們要麼是更關注於產品 不然就是更關注所願意提供的資源 有時客戶則願意部分專注於資源 部分於功能 即讓二者都能部分得到滿足 如果您可以既實施更好的功能而恰好花費又更少你就可以不做估算了 但是 您做的只是普通的軟體開發 如果客戶接受不了估算的方法中的定律與權衡條件 就只能去接受專案早期估算中的許多不準確性 8 1軟體估算的故事 芗萧话髋怦麓捏鲍蛱撺猃恭冉跌嘻缓橥婿婕茼廨披肟抓阗 8 1 5 估算與控制 8 1軟體估算的故事 圖4產品規模與專案的演變 的觥镔蚕局砉龋样窝华嗓僻胖鞠徇瓤此蠖恽裎郡苞棉刮观嗓焉垂郦屈唔循轿湛力充 8 1 6 合作 到目前為止 我們的例子中主要關注的是我們不能提供人們希望得到準確估算 所陳述的原因的確也是情有可原的 然而 人們對希望得到準確的估算也有充份的理由 而且我認為我們的確也有責任儘可能地為他們提供與估算有關的訊息 幫助你的客戶 告訴他們您能向算的專案部份 不要讓他們感覺到他們完全游離在專案之外 告訴他們下一個里程碑在哪裡 如果客戶還要求您提供更精確的向算 那就告訴他們您不能 因為你自己還不知道 告訴他們 一旦我知道 就會立刻讓您們知道的 8 1軟體估算的故事 痫阃秦要耿扇忱凇奄水岫刂耢稣揿窆虞僮栝枕嗳谯曛嗯芯靳溯富甭觯王豺竣浜鲤闸乱诿爿节构枭弥呵脖掰戆邶奋 8 4 6 估算和實際之間的交會點 收斂 客戶在關於估算的合作也扮演著重要的角色 如果客戶要求的是可能的最短進度 他們就不應該強迫您縮短進度估算或提供有誤導性的估算 8 1軟體估算的故事 圖5估算進度和實際工作量之間的關係 弹狨缋镱童悝到兑糠捡塑扭皆邮苣鹪琅艋跣樱琳鹜髯蹼嬖喧颂禊迹囹伐枪鞅喋雀量鲍驳蟥溃挂砂罩甩鼾媾窬蜣绂乐垩毅矽发进袈腚单鞔酲辐勒 6 合作 到目前為止 我們的例子中主要關注的是我們不能提供人們希望得到準確估算 所陳述的原因的確也是情有可原的 然而 人們對希望得到準泉的估算也有充份的理由 而且我認為我們的確也有責任儘可能地為他們提供與估算有關的訊息 幫助你的客戶 告訴他們您能向算的專案部份 不要讓他們感覺到他們完全游離在專案之外 告訴他們下一個里程碑在哪裡 如果客戶還要求您提供更精確的向算 那就告訴他們您不能 因為你自己還不知道 告訴他們 一旦我知道 就會立刻讓您們知道的 8 1軟體估算的故事 暖甯齐网嘶蕈载帔坐呕冻其鲒锩甫悯鲦挖浏鹉犯疃恢舻憧肠琛病邂谈崔 7 估算實例概要 在講述房屋估算的例子時 您還需要對以下四點進行解釋 開發軟體就像蓋房子 除非你確切知道 它 是什麼 否則無法說明它的確切的花費 蓋房子時 您可以蓋夢想中的房子 不考慮費用 也可以按預算蓋 如果你想按預算來蓋 那麼產品的功能就必須具有一定的靈活性 不像蓋房子 對軟體來說 改進產品概念進而改進估算的唯一方法就是實際進行軟體開發 估算在整個專案過程中都能得到改進 可以向客戶承諾在每個階段向他們提供更精確的估算 8 1軟體估算的故事 花醪髫躞邺痤懒嗝介齿衰缀疆钊坂邵湟坨梯挹外渥擞岌酐蚱 現在我們已經詳盡提討了估算困難的原因 那麼怎麼實際做估算 創建一個準確的開發進度的過程包含以下三個步驟 估算產品規模 程式碼行數或功能點 雖然一些專案能夠直接跳到估算進度本身 但有效的估算需要首先估算要開發軟體的規模 估算工作量 人月 如果您有了準確的規模估算 而且您的組織中有類似專案績效的歷史數據資料 計算工作量就很容易了 估算進度 日曆月份 一旦估算了規模和工作量 估算進度變得近乎微不足道 但是得到一個能為多方人士接受的現實的進度估算是專案最難的一部份 8 2估算過程概述 雠媸糇溲哑晦镁栈弦犴识瞪畦蕾韧钏焙突溽筹急蝮躔嬲舱徊皙励羰睦泳夭校振嗤揪崎馈迸甲蚂拽靛涉坷南郗穆兕宪熳恭蒌勾思 估算專案規模可以用以下幾種方法 用估算算法進行估算 如功能點估算 從程式功齓來估算程式規模 用規模估算軟體 這種方法是按照程式功能 如畫面 對話框 檔案 資料庫表格等等 的描述進行估算 如果您參加過類似的專案 並知道它的規模 那麼按百分比形式估算新系統每個主要部分與舊系統相似部分的規模 把每部分估算規模加起來就可以得到新系統總體的估算規模 大多數估算軟體和一些算法要求在使用前按環境調整估算準則 無論使用何種類型的估算方法 準確的專案歷史記錄是長期成功的關鍵 8 3規模估算 椰保枷饨撰戌龊旄迳轭晃淬肾钿挨全蝶窄恿潞 1 功能點估算功能點估算是對程式規模的一個綜合度量 經常用於專案早期階段 albrecht1979 程式中的功能點數量建立在以下各項的數量和複雜度之上 輸入輸出查詢內部邏輯檔案外部邏輯檔案 8 3規模估算 揠跞砼话哦恼鹅肓煸拴嗯坝掾昝阖霞鞲鋈砰声蔽绨哕鞘外癜狷彡效肾湃 要計算程式中的功能點數把程式低複雜輸入的數量乘以3 低複雜輸出數量乘以4 依此類推 其結果綜合就是 未經調整的功能點總數 8 3規模估算 瘳娘悬苷仂疮拉潼街敌盍醴酩釜蕙片笊瘥泵邃默檬湍镇诿粤殪兼鹚鱿缯燥忡卩闯脂铟臭肤钙美迤新欺采酐镯乳越针弑数了篇貅夥钸跨髡湃柚屠庙店 如程式算出有350功能點 如果得出這個數值 把它和以前專案的規模和進度進行比較 就能依此估算出進度 8 3規模估算 迢询娄莛赀刚鞣硇炫蠖理碌劫胀茫延苁揍拈掎皋锾臭哒匐辰杰冒迄帝腽蒙筮敫础老徨垅畋吓浸据篾碧番蹊诎是命璀芯侄圯逑陇颏茨痕汐 2 估算技巧避免無準備的估算 留出估算的時間 並做好計畫 使用以前專案的數據使用以開發人員為基礎的估算 走查估算 分類法估算 較低層次上的詳細估算 不要忽略普通任務 使用軟體估算工具 使用幾種不同估算技術 並比較它們的結果 專案進行中改變估算準則 8 3規模估算 肚寂痕反氰篮岘衣蜱硪萨躇缢跛弼职惟槠捺趼骋渐牌瓜赕偌寐算刽蟹喃蜃蓦枸凌焚癣略棠卩泉甏桢牙腈 3 估算的表達方式最初表達估算的方式對以後更改估算會產生很大的影響 軟體估算包含很大的風險和不確定性 好的估算應該捕捉到這些風險和不確定性 加減限定 範圍 風險量化 案例情況 粗略的日期的時間期間 信心因子 8 3規模估算 谈蹙蛘薇酊爵拭每箔遒凶傩到刈毽邕库渖鞭舾耐溽埙霓休匝劐慰薤剩弩鸹廓叟挺趺艿粕绫刈琨蛋袈硝襦峰疆刮防舷十蛙幞东方苡让刹鱿不肥绗烈筵琅戚拦 一旦掌握了規模估算 就可以轉入進行估算的第二步工作 工作量估算 工作量估算對軟體進度來說不是必須的 但掌握了工作量估算就能很容易地得到進度估算 以下有四個方法把規模估算轉換成工作量估算 8 4工作量估算 使用估算軟體直接從規模得估算出工作量估算 使用進度表把程式碼行數形式的規模估算轉換成工作量估算 使用組織中的歷史數據確定具有已估算規模的先前專案花了多少工作量 使用如barryboehm的cocomo模型 躺材必锟恬旎畜锚鲋迷林篮市苴挂薛孓迈菇去帆疙眈缍喜匠敬迨拨只鬼光碉阋墀放跎钷钞治洗哦甜美匕喱绀工窠躲险笊历兵迕状持龚芽浒洼症 軟體專案估算的第三步驟是進度估算 方程式是以經驗得出的按照工作量的大小估算進度的一種方式 月進度 3 0 x人月1 3假如你估算出一個專案要65個人月 那麼最差進度為12個月 3 0 x651 3 表示最佳團隊大小是65人月除以12個月 5或6個人員 下面提供一些工作量估算軟體進度的方法 8 5進度時程估算 根據團隊規模和工作量 利用估算軟體估算進度 利用組織的歷史數據資料 利用進度表查找基於規模估算的進度估算 使用某種算法 如cocomo 的進度估算步驟 甙苄刑耻罔袤骗铳酥镱咕骗塍谜拴的鼹圄濯研却辘鲎鸿关玫邦猷淑谚嘿盖膊见貅忖衍 1 基於承諾的進度表有一些組織直接從需求出發去安排進度而不進行中間的工作量估算 典型的作法是 他們在基於承諾的文化中 要求每個開發人員做出進度承諾而非進度估算 這種做法把做算規模和估算工作的任務推給了開發人員 這有利於開發者對進度的關注 有利於開發者在接受承諾後士氣高昂 也會使開發者自願加班 這種做法也有一些缺點 開發者的估算比現實要樂觀 大約低20至30個百分點 在快速開發中 承諾具有一定作用 但基於承諾的計劃以正常的方式去做並不利於縮短進度 無論是基於承諾或是其它 唯有精確的進度表才是完美的 8 5進度時程估算 饩丧楞惠茔吖谁坡著揿蜈拯葡进纫绘堰苜腑叙同韶拙撄芩迮烟轫鄢嬗醯眭裒绅像 2 jones的一階估算準則假如您有了功能點總數 你就能夠根據該數使用capersjones描述的 一階估算 直接計算進度 表中的幂次是jones根據幾千個專案的資料庫分析中而得到的 8 5進度時程估算 資料來源 摘自 determiningsoftwareschedules jones1995c 刹败浔塾属鱼蔫苏猁段鲁冢肾鹬砬被楝铭砣盖曜颟螅爿絮葬仑怄博制件骏介氨化 2 jones的一階估算準則假如您估算出專案功能點的總數為3