Ⅰ 估算軟體工作量多少或大小時如何選擇合適的方法
在估算軟體工作量時選擇哪種方法好，我覺得你應該先了解一下軟體項目工作量的估算方法主要有哪些。通常用的就3種：方程法、類比法和類推法。一般情況下估算軟體項目工作量是由估算軟體規模的結果作為輸入，然後採用方程法來進行估算。但也有一些特殊情況，比如需求非常模糊而無法進行規模估算時，可以直接採用類比法或類推法來估算軟體工作量。
以我個人的經驗，在估算軟體項目工作量時，如果你對於上面說的3種方法的使用足夠了解，是可以很容易選擇出合適的方法的。有關這3種方法的詳細介紹我認為你還是多去了解一下，或者系統的了解一下軟體成本估算方面的知識，畢竟工作量估算只是軟體成本估算中的一小部分。我可以推薦一本書給你，由北京軟體造價評估技術創新聯盟編寫機械工業出版社出版的《軟體研發成本度量規范釋義》第2版。或者也可以購買剛剛發布不久的國家標准《GB/T 36964-2018 軟體工程 軟體開發成本度量規范》來了解相關知識。
希望我的回答可以幫到你，如還有疑問可以跟我聯系溝通。
Ⅱ 在正式需1求分析前，怎麼盡可能准確估算軟體系統的工作量
同其他任何工程項目一樣，軟體項目同樣存在一個非常重要的問題，這就是軟體管理的問題，而這一問題通常容易被一般的軟體開發人員所忽視。在一般的軟體工程資料中所討論的重點也只是軟體開發方法，對軟體管理問題大多一筆帶過。在一個小的軟體開發項目中也許還無所謂，但一個大型的軟體開發項目如果沒有優秀的軟體管理人員來領導和協調整個項目，其失敗的可能性就很大了。因此有必要引起大家對此問題的重視，這也是本文的目的所在。 軟體管理工作涉及到軟體開發工作的方方面面，其直接對象包括人、財、物，簡單地說，人就是指軟體開發人員，財就是指項目經費，物就是指軟體項目。也許還沒有關於這方面的專門理論，但在工商管理領域已經有十分成熟的管理學理論，他山之石，可以攻玉，所以我們完全可以引進到軟體項目方面的管理。 作為軟體管理人員，應該站在高處來俯瞰整個項目，如果有不識廬山真面目的感覺就不太好了。有了俯瞰全局的意識這一前提，採用適當的管理技術，項目開展就容易羅。軟體項目的管理工作可以分位四個方面：軟體項目的計劃、軟體項目的組織、軟體項目的領導和軟體項目的控制，下面對這四個方面進行詳細的介紹。 編輯本段軟體項目的計劃 軟體開發項目的計劃包括定義項目的目標，以及達到目標的方法。他涉及到項目實施的各個環節，帶有全局的性質，是戰略性的。計劃應力求完備，要考慮到一些未知因素和不確定因素，考慮到可能的修改。計劃應力求准確，盡可能提高所依據的數據的可靠程度。主要工作集中在軟體項目的估算、軟體開發成本的估算和軟體項目進度安排。軟體項目計劃的目標是提供一個能使項目管理人員對資源、成本和進度做出合理估算的框架。這些估算應在軟體項目開始時的一段有限時間內作出，並隨著項目的進展進行更新。 軟體項目的估算 軟體項目管理過程開始於項目的計劃，在做項目計劃時，第一項活動是估算。現在已經使用的使用技術是時間和工作量的估算。因為估算是其他項目計劃活動的基石，而且項目計劃又未軟體工程過程提供了工作方向，所以我們不能沒有計劃就著手開發，否則就會陷入盲目性。 估算本身帶有風險，估算資源、成本和項目進度時需要經驗、有用的歷史信息、足夠的定量數據和作定量度量的勇氣。估算的精確程度受到多方面的影響。首先，項目的復雜性對於增加軟體計劃的不確定性影響很大，復雜性越高，估算的風險就越高。復雜性是相對度量的，他與項目參加人員的經驗有關，比如如果讓搞MIS的項目組去搞操作系統設計顯然增加了復雜性。其次，項目的規模對於估算的精確性和功效的影響也比較大，因為隨著軟體規模的擴大，軟體相同元素之間的相互依賴、相互影響也迅速增加，因而估算時進行問題分解也會變得更加困難。還有項目的結構化程度也影響項目估算的風險，這里的結構性是指功能分解的簡便性和處理信息的層次性，結構化 程度提高，進行精確估算的能力就提高，相應風險將減少。此外，歷史信息的有效性也影響估算的風險，在對過去的項目進行這綜合的軟體度量之後，就可以借用來比較准確地進行估算。影響估算的因素遠不止這些，比如用戶需求的頻繁變更給估算帶來非常大的影響。 估算的依據是軟體的范圍，包括功能，性能、限制、介面和可靠性。在估算開始之前，應對軟體的功能進行評價，並對其進行適當的細化以便提供更詳細的細節。由於成本和進度的估算都與功能有關，因此常常採用功能分解的辦法。性能的考慮主要包括處理和響應時間的需求。約束條件則標識外部硬體、可用存儲和其他現有系統對軟體的限制。 另外軟體項目計劃還要完成資源估算，包括人力資源、硬體資源和軟體資源。在考慮各種軟體開發資源時最重要的是人，必須考慮人員的技術水平、專業、人數以及在開發過程各階段對各種人員的需要。硬體資源作為一種工具投入。軟體資源包括各種幫助開發的軟體工具，比如??資料庫等。 工作兩估算是最普遍使用的技術。經過功能分解之後，可以估計出每一個項目任務的分解都需要花費若幹人年，總計之後就知道軟體項目總體工作量。下面就是一個示意性工作量估算表。 表格 1 某軟體系統工作量估算表（單位：人日） 任務 需求分析 設計 編碼 測試 小計 用戶定義 2 5 1 0.5 8.5 系統定義 2 5 1 0.5 8.5 廣告預定 4 10 2 0.5 16.5 劃版 5 20 10 0.5 35.5 製作和組版 3 5 3 1 12 總計 16 45 17 3 81 軟體開發成本的估算 軟體開發成本主要是指軟體開發過程所花費的工作量及其相應的代價。它不同於其他物理產品的成本，它主要包括人的勞動的消耗，人的勞動的消耗所需的代價就是軟體產品的開發成本。 開發成本的估算方法有很多種，象簡單的代碼行技術，任務分解技術，自動估計成本技術，專家判定技術，還有參數方程法，標准值法，以及COCOMO模型法。其中COCOMO (Constructive Cost Model)模型法是一種精確、易於使用的成本估算方法，該模型按其詳細程度分為三級：基本COCOMO模型、中間COCOMO模型和詳細COCOMO模型【3】。 軟體項目進度安排 軟體項目的進度安排主要是考慮軟體交付用戶使用的這一段開發時間的安排。進度安排的准確程度可能比成本估計的准確程度更重要。軟體產品可以靠重新定價或者靠大量的銷售來彌補成本的增加，但進度安排的落空會導致市場機會的喪失或者用戶不滿意，而且也會導致成本的增加。因此在考慮進度安排時要把人員的工作量與花費的時間聯系起來，合理分配工作量，利用進度安排的有效分析方法嚴密監視軟體開發的進展情況，以使得軟體開發的進度不致被拖延。 在進行進度安排時要考慮的一個主要問題是任務的並行性問題。當參加項目的人數不止一人是軟體開發工作就會出現並行情況。因為並行任務是同時發生的所以進度計劃表必須決定任務之間的從屬關系，確定各個任務的先後次序和銜接，確定各個任務完成的持續時間。另外還應注意關鍵路徑的任務，這樣可以確定在進度安排中應保證的重點。常用的進度安排方法有兩種，即甘特圖（Gantt Chart）法和工程網路法。 編輯本段軟體項目的組織 參加軟體開發的人員如何組織起來，使他們發揮最大的工作效率，對成功地完成軟體項目極為重要。 編輯本段組織結構 開發組織採用什麼形式由軟體項目的特點決定，同時也與參加人員的素質有關。通常有三種組織結構模式： 按課題組劃分的模式 ：把開發人員按課題組成小組，小組成員自始至終承擔課題的各項任務。該模式適用於規模不大的項目，並且要求小組成員在各方面有技術專長。 按職能劃分的模式 ：把開發項目的軟體人員按任務的工作階段劃分為若干工作小組。要開發的軟體在每個專業小組完成階段加工後沿工序流水線向下傳遞。這種流水作業的方式使用於多項目並行的情況。 矩陣形模型 ：這種模式是以上兩種模式的復合。一方面按工作性質成立一些專門小組，另一方面每一個項目都有它的經理人員負責。每一個軟體開發人員屬於某一個專門小組，有參加某一個項目的工作。該模式的優點有一方面參加專門組的成員可以在組內交流在各個項目中取得的經驗，這更有利於發揮專業人員的作用；另一方面，各個項目有專門的人員負責，有利於軟體項目的完成。這種模式比較適合於規模比較大的項目。 組織結構的最後一層是程序設計小組的組織形式。通常認為程序設計工作是按獨立的方式進行的，程序人員獨立地完成任務。但這並不意味著相互之間沒有聯系。一般在人數比較少時組員之間的聯系比較簡單，但隨著人數的增加，相互之間的聯系變得負責起來。小組內部人員的組織形式對對生產率有著十分重要的影響。
Ⅲ 軟體工程課題研究
1。區域網通信工具
要求:分server，client，可以發送文本信息，傳送文件、能支持多個client的連接(tcp)
最好有後台資料庫的支持，要求用戶注冊並登錄。
2。難度：一般
3。實現MFC或socket api 我作畢業設計時只懂C++，只是上過課，沒有項目經驗。
後來我到單位去作畢業設計，一邊作一邊學。最後開發出了一個包含資料庫、網路和多線程的程序。
關鍵是興趣、動力和壓力。有了這三個，進步很快。
可以作的項目多了，區域網聊天的伺服器端和客戶端，類OICQ軟體，類Foxmail軟體等等。
都基本符合畢業設計要求的難度和工作量。
Ⅳ 軟體生命周期 測試工作量占整個項目的多少
在整個軟體生命周期，每個階段都需要軟體測試的，而不是單純的軟體開發好以後擺在你面前，才叫做軟體測試的開始。從軟體需求說明書開始，測試工作就可以介入，一直到整到項目交付使用，測試工作一直持續進行，在客戶那裡發現問題、軟體升級、補丁等工作，測試工作都是一直在進行的，只是每個階段的工作量大小、工作內容都不同而已。
Ⅳ 估算一個軟體項目工作量多少時如何選擇合適的估算方法
一般看項目復雜性，功能點多少，開發人員水平這些因素吧。有明確的項目架構，產品功能版本規劃的，開發人員齊全穩定的，就估算得准確些。項目做什麼做哪些都不清楚，怎麼算，人員技術都不齊全的，遇到不會做的也很難說要多久。軟體開發流程一般都是需求-設計-開發-測試-發布，流程走得順利，不頻繁更改需求，打亂流程，就沒那麼多誤差。知道做什麼了，才按每人每天能做多少事了安排計劃，大概就能算出進度表了。
Ⅵ 軟體開發項目工作量如何評估，按人天、按代碼行、按模塊....飛過的高人請留步~~~
總的來說，要考評估一種/多種操作系統的開發復雜度及是否跨平台，軟體應用技術的復雜度，是否多個子系統構成及子系統相互通信技術，軟體應用范圍的廣度，受眾用戶的數量，軟體升級及更新的管理規劃，培訓安排等。。
1。需求確定的情況很少，因為客戶的需求總是在變，即使確定下來，驗收的時候也會提出新的問題，這個要靠項目經理溝通，用戶當前的問題在這個版本中解決還是下期合同來做。因此來說，需求大體確定以後，拆分子系統組成---子系統的組成模塊--細分模塊組成，這個是相對粗粒度的，然後就要考慮你手頭隊伍對細分模塊的開發實現能力，大體就知道工作量了，如果不趕工期，時間要放長，軟體開發，沒有一帆風順的，肯定會有很多問題，簡單來說就是常見的需求變更。
2。評估成員工作量，首先要了解隊伍組成，哪些人規劃流程清晰，哪些人對技術攻關能力更好，哪些人適合測試，哪些人編碼快速，哪些人對資料庫精通，哪些人對界面布局更擅長，哪些人有技術的同時更善於溝通。所以通常都是更善於溝通的做組長，及時把流程清晰的告訴組員，反饋每個組員的工作進度，協同組員進度並決定何時由何人做技術攻堅，何時組織測試。
3。項目完成以後就好統計了，每個小組的代碼行數，實現的功能模塊數量，供其他小組調用的模塊，用時多少天，涉及多少領域等，其實這個統計不能說a組完成項目的40%，b組60%這樣，比較合理的應該是在某個方面，各個小組的組成比例的表格，然後有個小組工作的總結比較合適。如代碼統計，a組2w行，佔40%，b組3w，佔60%。 模塊數量：a組6個，佔60%，b組4個佔40%，並附模塊結構的說明。當然，各個公司的管理不一樣，統計方式不一樣，反正一個原則就是盡量兄弟們多說點好話，因為一個軟體做成，每個環節都不能差的，再好的汽車，如果沒有一個很普通的小小鐵板當剎車踏板，你敢開嗎。
其實還有很多的，讓高人再補充吧，軟體管理，在中國一直落後的，大家一起努力。
Ⅶ 某軟體工程項目各開發階段工作量的比例如下表所示，怎麼得出d的。。請明白的教教我
29%+17%+13%+10%×1200/3000
Ⅷ 如何評估軟體項目的工作量（人/天）
一個工作或者是項目的工作量的評估，會牽涉到的因素確實比較多。根據經驗，羅列幾種因素，比如使用的方法或者工具、開發者的熟悉程度、以及(部門之間的)利益關系、對項目的理解評估人員的個性。基於各種因素考量最後出現的工作量評估會有比較大的區別。
1.使用的方法或者是工具
對於一個項目，A有些現成的模塊，B需要重新開始搭建，A和B對完成時間的評估自然不一樣。
或是對於開發一個網站，假設合理的工作量是，做前台展示頁面需要1個月，後台管理需要1個月。A會評估為1個月，等前台上線之後，再同步開始做後台管理。B可能會認為需要2個月，B認為前後台都完成，才是工作完成。
2.開發者的熟悉程度
這個容易理解，如果是一般對語言或是技術掌握不熟悉的人，花費的時間和返工的時間、溝通的時間自然就要長一點
3.(部門之間的)利益關系
公司之間的外包項目，服務方就傾向於時間長一點，考慮的因素是假設用戶需求會有一部分變化或者希望從中多賺錢。公司的部門之間也是類似，營銷部門總是希望越快越好，但是開發部門總是認為營銷部門沒有更早提出需求等等。
4.對項目的理解或者評估人員的個性
同樣一個項目，類似微信，如果1000個用戶數和1千萬的用戶數，做法上會有非常大的區別。
Ⅸ 應用軟體工程會增加系統工作量嗎
不會的呀，除非你以前都不記賬什麼的