visual c开发入行真功夫光盘二次软件工程基础项目管理

软件项目管、局的现代化系统银行的MasterNet系统等[2]，给客户和软件开发组织带来巨大的、件系统内在的逻辑复杂性往往导致难以控制和预见软件系统的质量以及软件开发过程中的主要关注以下面的对象：人员、产品和过程（见图1如何做1.1.软件项目和控作。因此，软件项目团队建设和管理须关注以下几下方面的问题。件项目的开发完全按照计划来执行软件项目和控制的任务是要软件项目的实际执项目进行和控制须关注以下几个方面的问题。软件管理的任务是要对软件开发过程中所产生的软件产品进行标识、、更动和，记录、至会导致软件项目。软件风险管理的任务是要对软件过程中各种软件风险进行识别、分析、预测、评估和，以避免软件风险的发生或者减少软件风险发生后给软件项目开发某软件开发公司现要为某个航空机票预订服务商开发一个基于Internet的机票查询和预订管理系统，该系统的功能描述见本书1.3节。该项目的合同额为50万元。在签订项目自合同签订日（200661日）起，在半年后（2006121日）交24小时的服务，以纠正试运行期项目组的成员均有丰富的软件开发经验尤其是项目组的曾经负责过类似项目。件项目的实施向公司的技术请教，希望能够获得以往软件项目所采用的过程或。软件过程模、险[1]；无法对软件项目进行计划、监督和控制；也势必影响软件项目组成员之间的交、瀑布模2所示。其特（1（3）（4）测测编2.快速原型模开开结初步分快速开发用户评估型（新需求建造3.件开发人员可以对软件系统进行设计、编码、测试和（见图3增量模增量式地实现和完善系统的功能和性能（如图4所示。增量模型的一个显著特点是软件系增量增量4.迭代模代螺旋模

5.入。每个循环迭代包括了以下四个阶段（见图6.Rup（RationalUnifiedProcess）是一种软件过程，它提供了在开发组织中分配任务和职Rup（7所7.Rup2.不要求地开发出完整软件系统，、Rup不仅是一个软件过程，而且还是一个过程产品和过程框架。作为一个过程框架，人工具相集成，从而为Rup的开发、和应用提供工具支撑。比如，IBM公司定期地发布RupRupBuilderRup进行剪裁和组织。、定义软件过件过程。定义和文档化软件过程大致步骤如图8所示。8.1.2.项目组可以针对软件开发组织或者软件项目的特殊情况和具体需要对软件过程模型中的软件集成试计划制定可以考将软系统的设计这软件开活动分3.6：认可、发布和培训项目组所采用的过程是什么，如何根据软件过程来实施项目等等。图9是Infosys公司软件 概要需软件 概要需求求规范 概要计文档 详细详细计文档代 单 代码集测 测单元测试计代试计试计构测系统测试计 安支安支改进软件过(1)10.2006127在原有的软件 增加有关验收测试的软件开发活动1011描述了一个软件过程变更请求的例子。一旦接受到过程变更请求之后，软件过程2006127在原有的软件 增加有关验收测试的软件开发活动11.案例分概求文概需

计文试计

详细详 计文 试计

程序代

软软软开发手册

确认试计确认测文档编

测程序代软件需求文

试计12.任务：集成各个软件模块进试。“？，公司对的这种回答不满意，他希望能够得到关于软件项目较为准确的定量描述。经过一番考虑后，回答说“项目估计需要7－8个月，成本大约需40－45万，公司负责人对这一数据极为，他进一步向问道“你是如何得到这组数据？”对此没。在开发过对软件项目的有关性质进行定量描述可以提供软件项目开发的可视度量、测量和估1.9米，某个软件的开发成本达1200万元。这类描述通常采用一些数字来描述事物的性质，属于（Metric（Estimation有效性试想如果一个项目实际的工作量是500个人（项目完成之后测量的结果，但是由于某些原因（如确的经验数据、过于乐观的估算等）在该项目实施前软件项目组100个人月，显然这一估算结果与实际的结果有很大的差距，如果按照大，开发该软件项目所需的成本和工作量相对而言也就越高。因此，在实际的估算过，自顶向下和自底向上的估算方12041000行代码。估算方基于代码行和功能点的估OfCode）和功能点（FunctionPoint）的估算方法中，利用代码行和功能点来表示软件系统通常依赖于程序设计语言的功能和表达能力采用代码行的估算方对那些设计精巧的软针对上述问题，人们提出用软件系统的功能数目来表示软件系统的规模。1979IBMFP=CT×(0.65+0.01×Fi)，Fi（i=1..140.650.01CT3所示，CT=（简单用户输入数×3＋一般用户输入数×4＋复杂数×10权权Fi（i=1..14）144。表4.Fi的取值表iFiFPCT(0.650.01×Fi)（i=1..14）FP=341(0.65×42)364.873645.ACT能点计算主要靠经验，因素比较多；此外计算功能点所需的数据不好。某种对应关系（6所示。根据该表的数据，一个功能点如果用汇编语言来实现大约需21行代码。从另一个角度上看，该表反映了不同程序设计语言的描述能力是不6.12C3456789代码L表示软件系统的规模（LOCFP来表示。针对一个具体a、悲观值b和一般值m，然后根据以下估算出软件项目规模的期望值e：e=(a+4m+根据软件项目规模的期望值e以及下列，就可以估算出软件项目的成本和工作量。PM=L/PM表示单个人月能够生产的功能点或者代码行数。CKL=S/其中，S为软件项目总开销，L表示软件项目的规模（单位：LOCFP)CKL表PMCKL值。因此，一旦估算出了软件项目的规模，获得了软本S=CKLL，也可根据PM=L/E计算出软件项目的工作量E=L/PM。成本为12000元，那么该软件项目的开发成本S=6800元364=247，5200元，工作量为E=364/8=45.5人月。Boehm在此基础上于1981年提出了 o模型用于对软件项目的规模、成本、进度等方面进行估算。Boehm把 o模型分为基本、中间和详细三个层次，分别支持软件开发的三个 o模型用于估算整个软件系统开发所需的工作量和开发时间，适合 o模型用于估算各个子系统的工作量和开发时 o模型用于估 o模型，其模型形式描述如下。Ea(kLOC)bE是软件系统的工作量(单位：人月)，ab是经验常数，其，c7.oabcd型。o模型有许多参数，其取值来至于经验值。该估算模型比较实用、易于操作，在o模型中的参数abcd3.01.122.5、0.35，那么根据模型E=a(kLOC)b可以估算出该项目的工作量是3.0*(33.3)1.12，152人月；然后根据D=cEd可以估算出该项目的开发时间是2.5*(152)0.35，即其它估算方、b，然后计算出每位专家估算的平均值Esti（a+4m+b）/6，最后根据各位专家的估算情况计算出最终的估算值Est=(Est1+Est2+Est3+……+Estn)/n目组拥有一批经验丰富的专家，可以考虑采用该方法。专家估算方法具有人为因素多、能导致软件项目。因此，在对软件项目的规模、成本和工作量等进行估算的过，50万到65万范围。应用利用o10％，而较实施过，软件项目实施之初，公司就提醒，为了更好地管理和控制软件开发项目，他应该马上着手制定软件项目计划。由于认识到软件项目计划的重要性花了一周时间制，，而，随着项目实施的进展发现实际的工作很难按照计划中所计划的那样开展进行。在软件项目计划不得不多次进行调整，项目进展一拖再拖。后来发现，低估项目规模的一，该案例提示我们制定软件项目计划是软件项目管理过一项非常重要的工作合理、有效的软件项目计划有助于软件项目对软件项目实施有序和可控制的管理确保软件基本概这里所指的活动和任务来自于软件过程它明确描述了软件开发过应做哪些方面的， 它们之间并不是一种线性的关系。如果某项软件开发活动投入3 约需16表示和分析软件项目计软件开发活动之间的关13时时活活动活动结束之后就开结束几天后开活动结束几天前开活动13.14同时开同时开开始几天后开开始几天前开活动活动B活A活14.15

进度计划的描

15. 。图是一种图形化的任务表示方式（如图16所示。它的横轴表示时间，纵轴对应于各个软件开发活动或任务图用矩形来表示软件开发活动或任务，矩形中的文字描述了。图16.见图17所需资源所需资源所需资源17.：，需要注意的是图和网络图二者是等价的，可以相互转换。用网络图描述的软件项目进度计划完全可以转换为用图来表示，反之亦然。相比较而言图的特点是更能：，关键路径分活活动4个工作活动2个工作活动7个工作活动2个工作活动活动2个工作活动D11个工作日活动5个工作活动8个工作在图18ABCDEFG。C、D、GH才能得以实施。显然，该软件项目A-B-C-HA-D-HA-E-F-G-H。其中，A-B-C-H22A-D-H18个工作日；A-E-F-G-H15A-B-C-H所需的工作日最多，因BC所需的工作日减少，比如在实际执行项目时，C5H就可7H3个3个工作日。活动责任矩动所需的角色（8。例如，针对需求分析这一软件开发活动，执行这一活动的是需求件项目和用户方批准需求分析活动的结果。8.用户方行详细说明。为此，需要进一步定义角色－人员责任矩阵（见表9。9.、、需求分析制定。件项目的具体要求（如进度要求、成本要求等并且要尽可能是合理和科学的，。制定软件项目计划的基础和19.软件项目计划的制定必须依据要开展的工作（即要开发的软件系统）假设通过估算某个软件项目的开发周期为6.5个月，成本大致需要25万元。制定软件项目计划的时（1）（2020.，估算软件开发活动的周估算软件开发活动的周期是制定软件项目进度计划中最为同时也是最为关键的任例如如果软件项目进度计划的制订者对软件项目需求分析活动的乐观估算结果是2个月，4个月的时间，显然需求分析活动的这一估算结果将使例如，要直接估算出一个软件项目需求分析活动的周期是比较的。在这种情况下，（2（3）（4）可以对该子活动作进一步的细分。比如，对于需求活动而言，如果其开发周期仍不能给（1）（2）3个月的时景和开发经验，可以大致估算出当前软件项目的需求分析活动的开发周期不会超出3个月。2140%-30%-10%-21.2081829日结束，但中间公司283110930101是，期间放假1周，因此该活动的计划结束日期应该是10月16日2天的时间。制定软件项目计划的步22.1.2.例如需求分析活动的周期估算和进度安排必须听取需求分析小组及其的意见如果软件项目计划所制定的计划要求需求分析小组在一个月内完成需求分析工作而需同样的如果软件项目计划和需求分析小组认为可以通过一周的集中来获取用户确定每个软件开发活动的软件项目软件项计划制的根软件过确定个软件发活动的这些软开发动的将代他们在的小组与软件目计划制定目计划制定可以和些协商他们所负责软开发活动的度、收集各个软件开发活动所提交的计划数3.软件项目计划对前一步骤所收集的计划数据进行分析，使用某些工具（如 最好利用某些软件工具 特图等方详细描软件项各项开活动的度排（2资源使软件发过各（中一项常重要工作软件项计划根据个软件发活动所提（如人员和设备等4.（1）（2）（3）（4）（5）5.应用软件项目计23.算

频繁与客户关系紧24.失败的软件项目计划往往是由于进度方面的压力确的估算和过于乐观的计划等方（1）软件项目和控，与进度同样问题的是从公司的财务部门得到通知，项目在需求分析阶段，件项目的执行情况进行和控制。软件项目的对软件项目的和控制是指在软件项目的实施过随时掌握软件项目的实际开软件项目在实施过会出现各种各样的问题和风险它们将对软件项目的开发产生消在项目过，软件开发人员必须识别各种软件开发问题和风险，对这些问题和风险进行描述和分析（如图26所示，并以风险的形式详细记录各个软件开发风险，包11软件开发活动问题 26.11. 提交人部分产品需求未得到潜在1所需的软件构件和工具没2软件测试所需设备比要求13需求分析阶段的开销超出104 析。表12月月 101127.12.软件开发活计实开始日结束日开始日结束日需2006-06-2006-06-2006-06-2006-06-需求分析和建2006-06-2006-06-2006-06-2006-06-撰写需求分析规需求评2006-06-2006-07-2006-06-2006-07-2006-06-2006-07-2006-07-2006-07-软件项目和控制的方图28.软件项目的和控制方图28描述了软件项目的和控制方法。软件项目和控制的基础包括两个方面：软件项目小组可以制定出如图29所示的报表，以便软件项目小组成员更好地××项××项目××年××月××日29.软件项目和控制的步软件项目和控制与软件项目开发之间的关系如图30所示。软件项目的和控制述了软件项目和控制的一般步骤。步骤1.成立软件项目小步骤2.召开软件项目会3.4.2否是图30.软件项目和控制与软件项目实施之间的关小成立软件项小成立软件项项目实施定期定期召开项会采采取措图31.软件项 需需对：目组带来损失。可以想象，小刘的离开将给项目组带来一系列问题小刘：软件风软件开发进度的滞后、用户的需求、软件开发成本的上升等等。件，而非也可以转化为。软件风险类计划、资源和产品的定义完全由客户或上层决定，忽略了软件项目组的意见，缺乏强有力、有凝聚力的管理层/决策的周期比预期时间长开发设施和工具不到位错误发生率高的模块，需要的时间对它进试和重构设计风 软件风险管理模鉴于软件风险的性和可变性等特点在项目实施过项目组人员和必须对管后。在这种情况，软件项目才采取相应的措施来处理风险（如抽调其他人员来小显然，无论是在风险缓解模式中项目组人员和在软件开发过有意识地识别各种软件风险，说，项目组人员和预先识别和分析哪些不好可能会发生，等它发生，并制定好这些发生后的应对措施。例如，项目组成员和已经知道小刘要离开项目组，但是没有采取任何措施来防止这一的发生，听任其发展，不过他们制定了相应的措施，一旦小刘离开项目组，来小刘的工作。显然，与管理和失败管理模式相比较，风险缓由来小刘的工作。在该模式中，项目组人员和不仅要识别软件开发过各种潜在的软件风险，而也就是说，项目组人员和预先识别哪些不好可能会发生，制定好了万一发生的应小刘的工作。同时，通过和小刘的交流发现，导致小刘离开项目组的主要原因是小软件风险管理方36包括：识别风险（（以及（。定36.风险评（1）（2）13.编风险名123456需求工法和定量表示方法二者之间有一定的对应关系（见表14。14.描0.8-0.6-0.4-0.2-0-15列举了软件开发风险及其发生概率。10.7。15.编123456需求分析小组开展需求工16.编损失(人周182435425366配合需求分析小组开展需求工根据每个软件风险发生的概率和损失，计算出它们的度=风险概率×风险损17表17.软件风险及其发生概率、造成的损失和度列编号风概损(人周度(人周182435425366配合需求分析小组开展需求工可以对软件风险的优先级进行排序。经过排序后的软件风险列表（18）清晰地显示了18.编号风概损(人周度(人周1866配合需求分析小组开展需求工35425需求分析分析所需的软件工作尚未到3位24需要注意的是，软件风险的度在软件过会动态地发生变化。比如对于编号为4，风险控（1）（2）（3）述有关软件风险处理的以下内容（如表19。表19.风险管理计划软件风险管理计风险编2风险名小刘离开项目风险发生的对小风险发生的原未风险可能发生的时二周消除风险的措由软件项目和小刘交互，询问离开软件项目组的真原因，并及时向反映情风险发生后的应对措让小陈小刘的工薪酬来消除发生软件风险的根源。表2020.风险描控制方制定质量保证计划，质量保证计划，安排专人负责质量证在风险评估和控制过，项目组人员和必须对软件风险的化解程度及其变：风险的主要内容包括和重要软件风险，记录这些软件风险度的变化生等等。表21描述了软件项目实施过软件风险的变化及其化解进展。：表21.风险本排上排周风险描化解进115功能蔓采取分阶段交付的方式，需和市场人员最终用户解255设计低要求按规范来进行软件设计，对软件设结果进行评324软件测试未到候选人员已经报给公司主管，最晚于下周确 案例分2222.编风概损(人周度(人周12配合需求分析小组开展需求工22软件风险管理计1求工由软件项目和用户方代表，希望用户方能够极协助需求分析小组开展需求工2由项目和公司管理层反应，希望能够得到软件需工作。此外，需求分析小组在第二周又发现了一些新的、潜在软件风险（见表23。23编风概损(人周度（人周3用户增加了额外的需34软件项目规模的估算结果过于乐3225212配合需求分析小组开展需求工 (2006-06-152006-06-2由需求分析制定针对本项目的软件需求规格说明书编34算5。深入分析，原先的估算仍然是比较合理的还在会议结果之后与公司的采购部分进行了，确保需求分析小组所需的软件工作能够按期到位。。软件低下等等提高软件系统质量的一个重要措施是在软件项目实施过要对待开发软件系统软件质McCall

可移植 可重用 产品运行37.McCall37McCall定义的软件质量要产品运行性。对于每一个视点，McCall提出了一组质量因素来描述从该视点所观察到的质关性。表2724.把软件从一个硬件配置/转移到另一个硬件配置/软件环境软件能够在其它应用系统的开发软件系统与其它系统相互交换信可对软件系统中的故障进行定位和修改以及对软件系统进行扩充的对软件系统进试以发现故软件满足规格说明以及实现用户软件在规定的进度下执行预期功控制未被人员程序和M