下载文档原格式
软件开发工作量评估软件开发工作量评估是项目管理的一项重要步骤，在软件开发过程中一般都需要它的帮助。
它是一种快速估计软件系统的开发量的方法，可以帮助到设计者更好地判断和估计软件开发所需要的工作量，并确定时间及成本。
软件开发量评估技术产生于上个世纪70年代，名为软件开发量评估模型（Software Development Effort Estimation Model，SDEM）。
这是一种基于数量的工作量估计模型，分析软件开发所需的工作量。
它主要用来估计软件开发工作量，并进行系统分析、设计、实施、安装和测试等任务分配。
它通过对软件上述阶段的活动耦合度分析，以及对软件开发中进程活动耗时尺度分析，确定软件开发所需的总体工作量。
具体来说，软件开发量评估包括：需求分析阶段，主要是分析用户、系统和设备之间的互动，并提出清晰的功能规格。
系统设计阶段，完成系统技术分析，系统可靠性、可用性分析及性能分析等，确定系统解决方案。
在实施阶段，根据解决方案，评估开发和实施所需要的工作量，包括进程流程安排和资源估算等以及测试阶段，包括模块测试、综合测试等，以及紧密集成的质量保证活动等。
为了有效评估软件开发工作量，需考虑如下因素：项目特点、开发技术水平和复杂性、工具的使用、项目的大小和质量要求等。
需要组织及时的会议，以确保开发团队共同指明项目的工作量。
此外，软件开发量评估过程还需首先采用团队手段，将团队成员参与其中，一起完成评估工作，以提升估计的可靠性和有效性。
之外，还可以借助现有技术，对测试进行量化，从而检测出软件产品可能存在的问题。
最后，软件开发量评估是项目管理中一项重要的组成部分，必须准确评估软件开发所需的工作量量，使得项目的投资回报在有限的资源上受到恰当的分配。
只有这样，才能保证项目的成功。
COCOMO II 软件项目管理中的成本估算方法如果没有事先成本估算和对资金、时间、人力有效的管理和控制，绝大多数项目都会超支和延误进度，甚至项目失败。
大多数模型都是专有的（如：SPR ’s CheckPint, Price-s, Jensen ’s model, Estimacs ）。
只有少数几种模型公开发表（如：COCOMO Softcost, Bailey-Basili ’sMeatamodel ）。
在公开的模型中，COCOMO 被广泛地接受和使用。
工作量评估的基本模型PM nominal = A X (SIZE)B✧ SIZE 是估算的软件功能单元的代码行数(千行);✧ 常数A 通常取值为2.94;✧ B 反映了项目的规模经济性；B = 0.91 + W i✧ Wi] X (SCED%) / 100 ✧ SCED 反映项目组面临的进度压力。
成本驱动：PM nominal = A X (SIZE)B X EM n i =1i今天的COCOMO II 模型已经有了相当的正确性，其估算的软件开发成本与实际成本相差不到20%，进度相差不到46%，很好的满足了项目决策和管理的需要。
COCOMO 估算模型改进研究摘要：针对代码行估算软件规模的不足，改进了软件规模的估算方法，并据此改进了COCOMO 工作量估算公式，应用实例证明，使用改进后的估算公式，估算准确性高于原COCOMO 工作量估算公式。
软件规模及度量有以下一些特征：✧ 软件规模是个模糊的概念，目前缺乏明确的定义；✧ 软件规模的大小只有近似值，并没有精确值；✧ 软件规模的度量必须服务于工作量和成本的度量目的；✧ 软件规模的度量独立于物理实现和开发技术；✧ 软件规模度量单位的选择可以根据不同应用环境而不同，其尺度的大小也可以不同。
软件属性可分内部属性和外部属性两大类[2]。
软件内部属性, 是指能够仅仅根据软件本身来进行度量的属性, 独立于其行为, 即“完全取决于自身”无需执行系统就可以对其进行度量, 如规模、复杂性和软件模块间的依赖关系; 软件外部属性, 是指只有考虑到软件如何与其环境相关的部分关联才能进行度量的属性, 如软件的可靠性、可维护性、可使用性和效率等。
如何对软件可行性分析引言在进行软件开发前，进行软件可行性分析是必不可少的步骤。
软件可行性分析可以帮助开发团队确定软件项目是否可行，并帮助他们了解项目的潜在风险和挑战。
本文将介绍如何对软件可行性进行分析。
步骤一：市场分析软件可行性分析的第一步是进行市场分析。
在市场分析中，开发团队需要了解当前市场上类似软件的竞争情况以及潜在用户对此类软件的需求。
市场分析可以通过以下方式进行：1. 调查竞争对手：了解竞争对手的软件特点、功能和优势。
这可以帮助开发团队确定自己的软件在市场上的定位和竞争策略。
2. 用户需求调研：通过问卷调查、面谈等方式了解目标用户的需求和期望。
这可以帮助开发团队确定软件开发的重点和关注点。
3. 市场趋势分析：研究市场趋势，了解市场上类似软件的发展趋势和用户需求的变化。
这可以帮助开发团队确保软件的长期可行性。
步骤二：技术可行性分析技术可行性分析是对软件项目所涉及的技术资源和限制进行评估。
在技术可行性分析中，开发团队需要考虑以下几个方面：1. 技术要求：确定软件项目所需的技术要求，包括开发语言、数据库、框架等。
这可以帮助开发团队评估是否具备开发所需的技术能力。
2. 技术资源：评估开发团队所拥有的技术资源，包括人员、设备和软件工具等。
这可以帮助开发团队确定是否满足项目的技术需求。
3. 技术限制：识别潜在的技术限制，例如硬件设备的限制、安全性要求等。
这可以帮助开发团队评估是否能够克服这些限制并顺利完成项目。
步骤三：经济可行性分析经济可行性分析是对软件项目的成本和收益进行评估。
在经济可行性分析中，开发团队需要进行以下几方面的考虑：1. 成本估算：评估软件项目的开发成本，包括人力资源、设备、软件工具等方面。
这可以帮助开发团队确定项目的开发预算和资源需求。
2. 收益预测：预测软件项目的潜在收益，包括直接收益和间接收益。
直接收益包括软件销售、服务费用等，间接收益包括品牌推广、用户留存等方面。
这可以帮助开发团队评估项目的商业价值。
软件成本估算方法的研究与改进作者：田永青来源：《电脑知识与技术》2008年第36期摘要：该文主要对常用的几种软件成本估算的方法进行了研究，并从它们具体的计算方法或者公式中得出了各自的优缺点，然后提炼出一种综合功能点估算和流行的COCOM0Ⅱ模型的新型估算方法。
关键词：成本估算；功能点估算；COCOM0Ⅱ中图分类号：TP311文献标识码：A文章编号：1009-3044(2008)36-2677-03Research & Improvement on Software Cost EstimationTIAN Yong-qing(School of Software Engineering, Tongji University, Shanghai 201804, China)Abstract: This essay mainly researched some usual methods of software cost estimation. From their idiographic calculational methods, the excellencies and defects of them have been educed, then a new method of colligation with FPT and COCOM0Ⅱ has been abstracted.Key words: cost estimation; FPT(Function Point); COCOM0Ⅱ(COnstructive COst MOdel)1 软件成本估算概述1.1 软件成本估算背景无法准确估算出软件开发的成本和进度是软件危机的重要表现形式之一，于是各种估算软件成本的模型和方法作为软件度量的一个方向应运而生。
何为软件成本估算呢？软件成本估算的含义就是指在软件开发以前对于其所需的工作量和时间等做出经验性的估计。
各类软件开发文档的英文缩写－适合用于文档编码文档名称英文简写工作任务说明书SOWProcess Handbook (项目过程手册)PHBEstimation Sheet (估计记录)ESTProject Plan (项目计划)PPLSoftware Management Plan( 配置管理计划)CMPSoftware Quality Assurance Plan （软件质量保证计划）QAPSoftware Risk Management Plan （软件风险管理计划）RMPTest Strategy（测试策略）TSTWork Breakdown Structure （工作分解结构）WBSBusiness Requirement Specification(业务需求说明书) BRSSoftware Requirement Specification(软件需求说明书) SRSSystem Testing plan (系统测试计划)STPSystem Testing Cases （系统测试用例）STCHigh Level Design(概要设计说明书)HLDIntegration Testing plan (集成测试计划)ITPIntegration Testing Cases （集成测试用例）ITCLow Level Design (详细设计说明书)LLDUnit Testing Plan ( 单元测试计划)UTPUnit Testing Cases （单元测试用例）UTCUnit Testing Report （单元测试报告）UTRIntegration Testing Report （集成测试报告）ITRSystem Testing Report （系统测试报告）STRRequirements Traceability Matrix (需求跟踪矩阵) RTMConfiguration Status Accounting （配置状态发布）CSAChange Request Form （变更申请表）CRFWeekly Status Report （项目周报）WSRQuality Weekly Status Report （质量工作周报）QSRQuality Audit Report(质量检查报告)QARQuality Check List(质量检查表)QCLPhase Assessment Report （阶段评估报告）PARClosure Report （项目总结报告）CLRReview Finding Form (评审发现表)RFFMinutes of Meeting （会议纪要）MOMMetrics Sheet （度量表）MTXConsistanceCheckForm（一致性检查表）CCFBaseline Audit Form（基线审计表）BAFProgram Trace Form（问题跟踪表）PTF。
缩略语与术语指南文件修改控制目录1．缩略语 (1)2 术语 (3)缩略语与术语指南 1 1．缩略语ACWP Actual Cost of Work Performed 执行成本BBD Baseline of Basic Design 基本设计基准BCR Baseline Change Request 基准变更请求BCWP Budgeted Cost of Work Performed 执行预算BCWS Budgeted Cost of Work Scheduled 初始预算BDD Baseline of Detailed Design 详细设计基准BIT Baseline of Integration Testing 集成测试基准BOS Baseline of Operational System 运行系统基准BPD Baseline of Preliminary Design 概要设计基准BRA Baseline of Requirements Analysis 需求分析基准BSC Baseline of Source Code 产品源代码基准BUT Baseline of Unit Testing 单体测试基准CAR Configuration Audit Report 配置审计报告CMM Capability Maturity Model 能力成熟度模型CSA Configuration Status Accounting 配置状态记录CSCI Computer Software Configuration Item 计算机软件配置项DP Defect Prevention 缺陷预防IC Intergroup Coordination 组间协调ISM Integrated Software Management 集成软件管理KP Key Practice 关键实践KPA Key Process Area 关键过程区域MR Meeting Record 会议纪录OPF Organization Process Focus 组织过程焦点OPD Organization Process Definition 组织过程定义OSSP Organization’s Standard Software Process 组织标准软件过程OST Operational Support Tool 支持工具OTE Operational Test Environment 测试环境/系统PCM Process Change Management 过程更改管理PM Project Manager 项目经理PR Peer Reviews 同行评审PSM Project Software Manager 项目软件经理QPM Quantitative Process Management 定量过程管理RAF Risk Accounting File 风险记录表RDS Requirements Documents 需求文档RF Risk Factor 风险指数RL Risk List 风险排序表RM Requirements Management 需求管理RMP Risk Management Plan 风险管理计划RQP Requirements Management Plan 需求管理计划RR Review Record 评审记录RTM Requirements Traceability Matrix 需求跟踪矩阵SCCB Software Configuration Control Board 软件配置控制委员会SCM Software Configuration Management 软件配置管理SCML Software Configuration Management Leader 软件配置管理负责人SCMP Software Configuration Management Plan 软件配置管理计划SDP Software Development Plan 软件开发计划SEF Software Estimation File 软件估计书SEG Software Engineering Group 软件工程组SEP Software Engineering Process 软件工程过程SEPG Software Engineering Process Group 软件工程过程组SMDB Software Measurement Database 软件度量数据库SMP Software Measurement Plan 软件度量计划SOW Statement of Work 工作陈述SP3 SPP Plan SPP计划SPE Software Product Engineering 软件产品工程SPI Software Process Improvement 软件过程改善SPP Software Project Planning 软件项目策划SPTO Software Project Tracking and Oversight 软件项目跟踪与监督SQA Software Quality Assurance 软件质量保证SQAL Software Quality Assurance Leader 软件质量保证负责人SQAP Software Quality Assurance Plan 软件质量保证计划SQM Software Quality Management 软件质量管理SRS Software Requirements Specification 软件需求规格说明书SW-CMM Software-Capability Maturity Model 软件能力成熟度模型TCM Technology Change Management 技术改革管理TL Test Leader 测试负责人TP Training Program 培训大纲TR Technique Report 技术报告TRD Technical Requirements Documents 技术需求文档WBS Work Breakdown Structure 任务分解书2 术语1.比较基准(Compared Baseline)：是在项目策划时得到的，是项目所有最初计划数据的集合。
Task statement1.Evaluate the business case for the proposed system development/acquisition to ensure that itmeets the organizationa’s business targets2.评估项目管理框架和项目governance pratices 来确保业务目标通过cost-effective的方式实现同时对组织的风险实施了有效管理3.检查项目的实施，确保其按照项目计划，并通过适当的文档支持和准确的status reports4.评估系统在设计、开发、采购、测试过程中的控制措施来确保其提供了安全防护且符合组织的策略和其他要求5.评估系统和基础架构的开发/获取过程，并测试保障交付物符合组织的目标6.评估系统在部署和迁移进生产系统时的readiness，7.执行postimplementation review来确保他们符合组织目标且有有效的内部控制8.执行定期检查保证系统持续的满足组织目标，且内部控制情况始终保持良好9.评估系统/基础架构的维护过程，确保其始终支持组织目标，维护良好的内部控制10.评估系统和基础架构的dispose过程，确保其符合组织策略和流程要求Knowledge statement1.benefits management practice：feasibility studies business case所有的项目的目的都是为了realize tangible benefits2.project governance mechanisms （steering committee，project oversight board）项目治理的程度与项目本身的复杂度有关3.项目管理实践、工具、控制框架项目管理有三方面的要素Hard factors:deliverables、quality、costs、deadlinesSoft factors:team dynamics、conflict resolution、leadship issues、culture differencies、communicationEnvironment factors：political and power issues、expectations of stakeholders、ethical and social issues。
软件工程量确认方案1.引言软件工程量确认是软件开发过程中重要的一环，其目的是正确、全面地确认软件项目的规模和工作量，为项目的计划、进度和成本控制提供可靠的依据。
本方案旨在介绍软件工程量确认的流程、方法和工具，以确保软件项目的顺利进行和顺利完成。
2.软件工程量确认的概念软件工程量确认是指根据软件项目的需求和规模，量化和确认开发过程中所需的工作量和资源。
通常包括以下内容：- 确认软件产品的规模和复杂程度- 确认软件开发过程中所需的人员资源和时间- 确认软件开发过程中所需的技术和设备资源- 确认软件开发过程中所需的成本和预算软件工程量确认的核心目标是为软件项目的规划和控制提供量化的依据，以确保项目的顺利进行和顺利完成。
3.软件工程量确认的流程软件工程量确认的流程一般包括以下步骤：- 对软件项目的需求和范围进行分析和理解- 对软件产品的规模和复杂程度进行评估和确认- 对软件开发过程中所需的人员资源和时间进行估算和确认- 对软件开发过程中所需的技术和设备资源进行预测和确认- 对软件开发过程中所需的成本和预算进行计划和确认在以上步骤中，需要运用一系列的模型、方法和工具，如函数点分析、原始代码行数估算、工作量估算模型等，以获得准确和可靠的软件工程量确认结果。
4.软件工程量确认的方法和工具软件工程量确认的方法和工具可以大致分为以下几类：- 函数点分析：通过对软件系统的功能点进行计数和评估，来量化系统的规模和复杂程度。
- 原始代码行数估算：通过对软件代码的行数进行统计和估算，来量化软件开发过程中的工作量。
- 工作量估算模型：通过对软件项目的需求、规模和资源进行建模和模拟，来量化软件开发过程中所需的人员资源和时间。
- 成本估算模型：通过对软件开发过程中的人力、物力和财力进行成本分析和预算，来量化软件开发过程中的成本和预算。
这些方法和工具在软件工程量确认中发挥了重要的作用，可以帮助开发团队准确地把握项目的规模和工作量，从而有效地进行规划和控制。
基于用例点进行软件估算作者：刘俊萍,李静静来源：《电脑知识与技术》2011年第27期摘要：目前用例模型作为一种捕捉和分析软件功能性需求的方法已经被广泛采用。
用例点估算方法正是以用例模型为基础的一种软件估算方法，该方法被证实是一种易操作、实用、可靠的估算方法。
该文将介绍如何使用该方法进行软件规模、工期、成本的估算，从而为项目计划和管理提供必要的数据支持。
关键词：UCP；用例点；软件估算中图分类号：TP309文献标识码：A文章编号：1009-3044(2011)27-6658-03Estimation Practices Based on Use Case PointsLIU Jun-ping, LI Jing-jing(Department of Information and Project, Zhengzhou Electric Power Technology College, Zhengzhou 451450, China)Abstract: Use case models are increasingly being used to capture and analyze the functional requirements of a software. It has been tested that use case points method that employs a project’s use cases is a reliable source of estimation. This paper provides an introduction to the use case points method for estimating the required man-hours, project schedule and cost of software development projects.Key words: UCP; use case points; software estimation在软件开发前期，制定适合的软件开发计划对于整个软件项目的管理和项目的成功都至关重要。
18thGeneral Books Beautiful Code Edited by Andy Oram and Greg Wilson (O'Reilly Media)Manage It! Your Guide to Modern Pragmatic Project Management by Johanna Rothman (Pragmatic Bookshelf) The Myths of Innovation by Scott Berkun (O'Reilly Media)Release It! Design and Deploy Production-Ready Software by Michael T. Nygard(Pragmatic Bookshelf)Technical Books Continuous Integration: Improving Software Quality and Reducing Risk by Paul Duvall (Addison-Wesley Professional) xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros (Addison-Wesley Professional)Head First SQL: Your Brain on SQL — A Learner's Guide by Lynn Beighley (O'Reilly Media)The Rails Way by Obie Fernandez (Addison-Wesley Professional)17thGeneral Books Agile Software Development: The Cooperative Game Alistair Cockburn (Addison-Wesley Professional) Catastrophe Disentanglement E. M. Bennatan (Addison-Wesley Professional)Practices of an Agile Developer Venkat Subramaniam and Andy Hunt (Pragmatic Bookshelf) Software Estimation: Demystifying the Black Art Steve McConnell (Microsoft Press)Technical Books Head First Object-Oriented Analysis & Design B. McLaughlin, G. Pollice, and D. West (O'Reilly Media) Code Quality Diomidis Spinellis (Addison-Wesley Professional)Refactoring Databases Scott W. Ambler and P.J. Sadalage (Addison-Wesley Professional)CSS: The Missing Manual David Sawyer McFarland (O'Reilly Media)16thGeneral Books Prefactoring Ken Pugh (O'Reilly & Associates)The Art of Project Management Scott Berkun (O'Reilly & Associates)Innovation Happens Elsewhere: Open Source as Business Strategy Ron Goldman and Richard P. Gabriel (Morgan Kaufmann) Producing Open Source Software: How to Run a Successful Free Software Project Karl Fogel (O'Reilly & Associates)Technical Books Agile Web Development with Rails Dave Thomas, David Hansson, Leon Breedt, and Mike Clark (Pragmatic Bookshelf) Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries Krzysztof Cwalina (Addison-Wesley) Practical Common Lisp Peter Seibel (Apress)Why Programs Fail: A Guide to Systematic Debugging Andreas Zeller (Morgan Kaufmann)15thGeneral Books Head First Design Patterns Elisabeth Freeman, Eric Freeman, Bert Bates and Kathy Sierra (O'Reilly, 2004) Joel on Software Joel Spolsky (Apress, 2004)Refactoring to Patterns Joshua Kerievsky (Addison-Wesley Professional, 2004)Software Factories Jack Greenfield, Keith Short, Steve Cook, Stuart Kent and John Crupi (Wiley, 2004)Technical Books Better, Faster, Lighter Java Bruce A. Tate and Justin Gehtland (O'Reilly, 2004)C++ Coding Standards Herb Sutter and Andrei Alexandrescu (Addison-Wesley Professional, 2004)Hibernate: A Developer's Notebook James Elliott (O'Reilly, 2004)Java Developer's Guide to Eclipse Jim D'Anjou, Scott Fairbrother, Dan Kehn (Addison-Wesley Professional, 2004)14thGeneral Books Waltzing with Bears Tom DeMarco and Timothy Lister (Dorset House, 2003)The Art of Unix Programming Eric S. Raymond (Addison-Wesley, 2003)Lean Software Development: An Agile Toolkit Mary Poppendieck and Tom Poppendieck (Addison-Wesley, 2003) The Pragmatic Starter Kit Dave Thomas and Andy Hunt (The Pragmatic Programmers, 2003)Technical Books Test-Driven Development: A Practical Guide David Astels (Prentice Hall PTR, 2003)About Face 2.0: The Essentials of Interaction Design Alan Cooper and Robert Reimann (Wiley, 2003)Agile Database Techniques: Effective Strategies for the Agile Software Developer Scott W. Ambler (Wiley, 2003) Code Reading: The Open Source Perspective Diomidis Spinellis (Addison-Wesley, 2003)13thGeneral Books Agile Software Development: Principles, Patterns and Practices Robert C. Martin (Prentice Hall, 2002)Documenting Software Architectures: Views and Beyond Paul Clements, Felix Bachmann, Len Bass (Addison-Wesley, 2002) Patterns of Enterprise Application Architecture Martin Fowler (Addison-Wesley, 2002)Test-Driven Development: By Example Kent Beck (Addison-Wesley, 2002)Technical Books Thinking in Java (3rd Edition) Bruce Eckel (Prentice Hall, 2002)Core Java 2, Vol. 1: Fundamentals (6th edition) Cay Horstmann and Gary Cornell (Prentice Hall PTR, 2002) Understanding Web Services Eric Newcomer (Addison-Wesley, 2002)PHP and MySQL Web Development Luke Welling and Laura Thomson (Sams Publishing, 2002)12thBooks Effective Java by Joshua Bloch (Addison-Wesley, 2001)Agile Software Development by Alistair Cockburn (Addison-Wesley, 2001) Software Craftsmanship by Pete McBreen (Addison-Wesley, 2001) Under Pressure and On Time by Ed Sullivan (Microsoft Press, 2001)11thBooks Adaptive Software Development by James A. Highsmith III (Dorset House, 2000)Don't Make Me Think! A Common Sense Approach to Web Usability by Steve Krug (New Riders, 2000) Writing Effective Use Cases by Alistair Cockburn (Addison-Wesley, 2000)Secrets and Lies: Digital Security in a Networked World by Bruce Schneier (John Wiley & Sons, 2000)10thBooks Software For Use: A Practical Guide to the Models and Methods of Usage Centered Design (Addison-Wesley, 1999) Extreme Programming Explained by Kent Beck (Addison-Wesley, 1999)Software Requirements by Karl E. Wiegers (Microsoft Press, 1999)After the Gold Rush: Creating a True Profession of Software Engineering by Steve McConnell (Microsoft Press, 1999)9thBooks Component Software—Beyond Object-Oriented Programming by Clemens SzyperskiAntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William Brown, Raphael Malveau Software Architecture in Practice by Len Bass, Paul Clements, Rick Kazman, and Ken BassThinking in Java by Bruce Eckel8thBooks The Deadline: A Novel about Project Management by Tom DeMarco (Dorset House Publishing, 1997) UML Distilled by Martin Fowler with Kendall Scott (Addison Wesley Longman Inc, 1997)Building Object Applications that Work by Scott Ambler (SIGS Books/Cambridge University Press,1997) Object-Oriented Software Construction, Second Edition by Bertrand Meyer (Prentice Hall PTR, 1997 )7thBooks Rapid Development: Taming Wild Software Schedules by Steve McConnell (Microsoft Press, 1996)The Distributed Objects Survival Guide by Robert Orfali, Dan Harkey, Jeri Edwards (John Wiley & Sons, 1996)Creating a Software Engineering Culture by Karl E. Wiegers (Dorset House, 1996)Pattern-Oriented Software Architecture: A System of Patterns by Frank Buschmann, Michael Stal (John Wiley & Sons, 1996)6thBooks Thinking in C++, by Bruce Eckel (PTR Prentice Hall Inc.)About Face: The Essentials of User Interface Design, by Alan Cooper (IDG Books Worldwide Inc.)A Discipline for Software Engineering, by Watts Humphrey (Addison-Wesley Publishing Co.)What Every Programmer Should Know About Object-Oriented Design, by Meilir Page-Jones (Dorset House Publishing)5thBooks "Essential Client/Server Survival Guide," by Robert Orfali, Dan Harkey, and Jeri Edwards (Van Nostrand Reinhold) "Debugging the Development Process," by Steve Maguire (Microsoft Press)"Design Patterns," by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (Addison-Wesley Publishing Co.) "The Design and Evolution of C++," by Bjarne Stroustrup (Addison-Wesley Publishing Co.)4thBooks Code Complete by Steve McConnel (Microsoft Press)Object-Oriented Design and Analysis with Applications, Second Edition by Grady Booch (Benjamin/Cummings) Applied Cryptography, by Bruce Schneier (Wiley & Sons)The Design and Evolution of C++, by Bjarne Stroustrup (Addison-Wesley Publishing Co.)Programming on Purpose, by P. J. Plauger (PTR Prentice Hall)Writing Solid Code, by Steve Maguire (Microsoft Press)3thBooks "Undocumented Windows," by Andrew Schulman, David Maxey, and Matt Pietrek (Addison Wesley Publishing Co.) "Decline and Fall of the American Programmer," by Ed Yourdon (Yourdon Press)"Object-Oriented Software Engineering: A Use-Case Driven Approach," by Ivar Jacobson, Magnus Christerson (ACM Press) "Liter Programming," by Donald Knuth (Stanford University Center for the Study of Language and Informaiton)"Effective C++," by Scott Meyers (Addison Wesley Publishing Co.)。
Software Estimation估算主要包括以下几个重要内容：◆ 规模估算软件估算首先要将整个工程的规模估算出来，才能进行下面的其他估算。
规模，就是一个工程可量化的结果，是用具体数字来体现项目的描述。
规模估算的信息来源是清晰、有界限的用户需求。
◆ 工作量估算这是对开发软件所需的工作时间的估算，它和进度估算一起决定了开发团队的规模和构建。
通常以人时、人天、人月、人年的单位来衡量，这些不同单位之间可以进行合理的转换。
◆ 进度估算进度时项目自始至终之间的一个时间段。
进度以不同阶段的里程碑作为标志。
进度估算是针对以阶段为单位的估算，而不是对每一个细小任务都加以估算，对任务的适当分解很重要，分解得越细反而会不准确。
因为任何一个软件工程，在各个方面都有与生俱来的不确定性。
◆ 成本估算包括人力、物质、有形的、无形的支出成本估算，其中以人力成本为主要部分。
比较容易被忽视的使学习成本、软件培训成本、人员变动风险成本、开发延期成本等，一些潜在成本消耗。
3、估算的策略在软件估算的众多方法中，存在着“自顶向下”和“自底向上”两种不同的策略，两种策略的出发点不同，适应于不同的场合使用。
3．1、自顶向下的策略这是一种站在客户的角度来看问题的策略。
它总是以客户的要求为最高目标，任何估算结果都必须符合这个目标。
其工作方法是，由项目经理为主的一个核心小组根据客户的要求，确定一个时间期限，然后根据这个期限，将任务分解，将开发工作进行对号入座，以获得一个估算结果。
当然由于这完全是从客户要求出发的策略，而由于软件工程是一个综合项目，几乎没有哪个项目能完全保质保量按照预定工期完工，那么这样一个策略就缺少了许多客观性。
但是由于这样完成的估算比较容易被客户、甚至被项目经理所接受，在许多公司我们看到这样一个并不科学的策略仍然被坚定地执行着。
3．2、自底向上的策略与自顶向下的策略完全相反，自底向上的策略是一种从技术、人性的角度出发看问题的策略。
在这样一个策略指引下，将项目充分讨论得到一个合理的任务分解。
在将每个任务的难易程度，每个任务依照项目成员的特点、兴趣特长进行分配，并要求进行估算。
最后将估算加起来就是项目的估算值。
显然自底向上的这种策略具有较为客观的特点，但是它的缺点就是这样一来项目工期就和客户的要求不一致了。
而且由于其带来的不确定性，许多项目经理也不会采用这种方法。
4、估算的方法显然估算是建立在客观实际上，对未来尽可能合理的一种预测。
那么估算本身的不确定性，决定了它不可能是百分之百准确无误的。
在项目刚开始时，人们对产品需求、技术、市场预期、人员素质等因素的了解还远远不够，在这种情况下人们很难作出准确的估计。
但是依据某种方法进行估计显然比瞎猜好得多。
估算方法有很多，大致分为基于分解的技术和基于经验模型两大类。
基于分解的技术的方法包括功能点估算法、LOC估算法、MARK II等；基于经验模型的方法包括IBM模型、普特南模型、COCOMO模型等。
4．1、FP功能点估算法功能点估算法是一种在需求分析阶段基于系统功能的一种规模估计方法。
通过研究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特性。
这种方法的计算公式是：功能点=信息处理规模x技术复杂度。
信息处理规模包括各种输入、输出、查询、内部逻辑文件数、外部接口文件数等等；技术复杂度包括性能复杂度、配置项目复杂度、数据通信复杂度、分布式处理复杂度、在线更新复杂度等等。
4．2、LOC估算法这是一种从技术的角度来估算的方法总称，其中又包含许多方法。
这类方法以代码（LOC）作为软件工作量的估算单位，在早期的系统开发中较为广泛使用。
基于LOC的估算，又有点也有缺点。
优点在于方便计算、容易监控、能反映程序员的思维能力；缺点在于代码行数的含糊不清，不能正确反映一项工作的难易程度以及代码的效率。
因此在传统的LOC方法进行了许多改进。
其中不断被使用，且不断演化的方法包括以下：PERT功能点估算法：PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。
用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计，Pert 估计可得到代码行的期望值和标准偏差SD。
∙类比估算法：类比法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。
类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。
∙Delphi估算法：Delphi法是一种专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别。
对于需要预测和深度分析的领域，依赖于专家的技术指导，可以获得较为客观的估算。
通过专家们的互相讨论，还可以博取众长。
∙系统分解：将系统分成若干个易于用LOC估算的部分，将其各个估算结果累加就是LOC的总规模。
其中关键是建立起SBS（系统分解结构），它描述了系统的不同组件。
SBS还被使用在其他重要的地方，如系统设计、系统分析等。
在进行分解的时候，可以采用自由讨论的形式，可以获得更合理的SBS构成。
4．3、IBM模型估算法该模型是Watson和Felix在1977年发布的，是基于IBM联合系统分布负责的60个项目的总结而得到的模型。
该模型是一个静态模型，而参考数据只有60多个项目，因此有很大的局限性。
4．4、COCOMO估算法Boehm在其经典著作“软件工程经济学”(software engineering conomics)中，介绍了一种软件估算模型的层次体系，称为COCOMO(构造性成本模型，COnstructive COst MOdel)，它代表了软件估算的一个综合经验模型。
COCOMO 模型是适用于三种类型的软件项目：(1)组织模式——较小的、简单的软件项目，有良好应用经验的小型项目组，针对一组不是很严格的需求开展工作(如，为一个热传输系统开发的热分析程序)；(2)半分离模式——一个中等的软件项目(在规模和复杂性上)，具有不同经验水平的项目组必须满足严格的及不严格的需求 (如，一个事务处理系统，对于终端硬件和数据库软件有确定需求)；(3)嵌入模式——必须在一组严格的硬件、软件及操作约束下开发的软件项目(如，飞机的航空控制系统)。
4．5、软件方程式估算法软件方程式是一个多变量模型，它假设在软件开发项目的整个生命周期中的一个特定的工作量分布。
该模型是从4000 多个当代的软件项目中收集的生产率数据中导出的公式。
初期的方程式较为复杂，通过，Putnam 和Myers的努力又提出一组简化的方程式。
当然这种方法也是基于长期的参考数据的积累而得到的。
4．6、WBS估算法这是一种基于WBS（工作任务分解）的方法，即先把项目任务进行合理的细分，分到可以确认的程度，如某种材料，某种设备，某一活动单元等。
然后估算每个WBS要素的费用。
采用这一方法的前提条件或先决步骤是：1.对项目需求作出一个完整的限定。
2.制定完成任务所必需的逻辑步骤。
3.编制WBS表。
项目需求的完整限定应包括工作报告书、规格书以及总进度表。
工作报告书是指实施项目所需的各项工作的叙述性说明，它应确认必须达到的目标。
如果有资金等限制，该信息也应包括在内。
规格书是对工时、设备以及材料标价的根据。
它应该能使项目人员和用户了解工时、设备以及材料估价的依据。
总进度表应明确项目实施的主要阶段和分界点，其中应包括长期定货、原型试验、设计评审会议以及其他任何关键的决策点。
如果可能，用来指导成本估算的总进度表应含有项目开始和结束的日历时间。
除了以上介绍的几种方法外，还有一些其他的方法：类比估算、推测估算、Standard-component估算法、普特南估算法等。
当然不同的方法适用于不同的具体环境，有些方法虽然很好但并不一定适合当前的任务。
只有量体裁衣，具体问题具体分析，才能得到尽量合理的估算。
5、估算的戒律记住：应该满足于事物的本性所能容许的精确度，当只能近似于真理时，不要去寻求绝对的准确⋯⋯——亚里斯多德对于任何一个项目经理，都知道要慎重估算，但是我们仍然会看到人力资源的浪费和财力资源的匮乏，在许多项目中存在。
对于宝贵的资源，我们不是用得太多，就是根本不够用。
因此，有以下前人总结出来的一些经验以供借鉴。
1.不要追求完美：就像没有人能预测出未来，如果还没有完成，就不要企图完美的结果。
更何况估算的太精确，反而会失去灵活机动的空间。
2.不要为满足预算而估算：如果这个项目的预算根本不能完成100%的任务，那么就不要让你的团队委曲求全。
正确地反映客观现状，不仅可以争取应得的权利，而且是完成任务的前提。
3.不要随意削减估算结果：有很多老板喜欢把项目经理递交的估算，不假思索地砍掉一部分。
这是一种不负责任的做法，如果要削减一定要有理由。
4.客观地估算，不贪多不偷减：就像老板不能随便削减你的估算一样，你也同样不能在估算的时候，贪多或是偷减。
贪多必然导致会浪费，偷减必然导致不足。
这两个结果恐怕都不是一个合格的项目经理的作为。
5.客观利用过去的经验：对于以往估算的经验，当然是宝贵的财富，但是如果财富用错了地方就会变成垃圾。
在使用经验时，要注意现在和参考经验之间的差异。
不要忘记，随着时间的推移，计算机领域技术的更新，许多观念都在发生着改变。
6.不要以客户目标作为估算的结果：客户是上帝，软件公司一定要尽力实现客户的需求。
但我们要实现的是合理的目标，况且不能为了完成目标而去堆积数字，这样岂不是因果倒置了。
7.不要隐匿不确定的成本：软件开发中存在潜在风险，是很正常的事情。
现在风险就会带来潜在的成本，如：突然一位程序员离职，导致工作进度路落后。
我们不可能估算到任何一种可能发生的情况，但有责任把可能出现的一些关键环节列出来。
