2025年软件项目管理体系与实践深度解析

大连理工大学软件学院软件项目管理大作业“政府公文审批及工作通告”应用程序软件项目管理1.1需方协议环境………………………4 4 5 5 6 6 6 6 6 6 77 3.1.2需求变更管理 5.规模估算 6.项目进度 21 8.配置计划…………………… 9.风险计划 9.1风险识别与评估 32 33 14.项目结束 14.5项目总结 第一部分协议管理1.1.1协议准备·招标文献XX省委需要引入一套“政府公文审批及工作通告”应用程序，现向社会标须知(投标须知略)1.投标文献发售时间：6月8日至6月18日工作时间内3.投标文献售价：¥10,000(售后不退，不接受邮购)5.投标截止时间：6月30日北京时间10:00时6.开标时间：7月1日北京时间14:00时五.有关规定：1.超过投标截止时间、不按规定密封的投标或不按《招标文献》规定提交有效足额投标保证金(以汇票、支票、现金支付)的投标，恕不接4.账号：345六.联络：XX省省政府邮编：000000电话：(02X)10000000传真：(02X)10000000招标书详细内容包括技术规定、商务条款、投标人须知、评标措施原则和XX省委省政府(即需方)通过公布招标文献、招标、搜集供方的提议XX省委省政府根据采购资料进行协议草案指定、草案评审、修订等程序，最终确定协议草案(协议草案略)。1.1.2协议签订XX省委省政府与大连理工大学(本文假设大连理工大学投标成功，该项目由大连理工大学下发至大连理工大学软件学院承担设计、开发、安装调试等一系列工作，内部部门人员配置同软件企业相似，借用大连理工大学之名而已。即大连理工大学为供方)以XX省委省政府提出的协议草案为基础，通过确定谈判日程、协议草案提交、协议条款协商、确定协议签订文本、协议签订文本审阅、协议签订的流程完毕协议签订。最终形成协议签订文本以及任务下达书。并将任务下达书分发给各中标单位(此处设该项目仅有大连理工大学一1.1.3协议管理XX省委省政府根据协议准备和协议签订时确定的需求资料及协议文本制定验收清单。对验收清单评审后制定验收计划，并按验收计划执行，得到验收在协议执行期内，假如协议双方XX省委省政府或大连理工大学有违约事件。需根据违约事件汇报进行违约事件通告，确定处理方式后按计划处理违约1.1.4协议终止过程XX省委省政府与大连理工大学根据协议及有关文档，公布协议终止告1.2.1协议准备大连理工大学(仅以大连理工大学为例)根据招标书安排项目分析任务。通过需求管理者确定、需求分析、需求分析评审、项目规模估算、项目风险分析、项目初步实行规划、初步实行规划评审，最终得到需求分析汇报和项目初大连理工大学按照需求分析汇报和项目规划进行竞标，通过技术能力规定确定、人力资源规定确定、实现环境规定确定、资金管理规定确定、能力鉴定、评估成果审评等评估，并进行需求成熟度评估、顾客支持保证评估、顾客资金保证评估、可行性分析、项目决策、编写项目提议书等环节，根据项目提大连理工大学根据XX省委省政府提出的采购资料制定协议草案。在经评1.2.2协议签订1.2.3协议管理大连理工大学以项目计划为基础，进行项目计划审批和协议执行管理规假如需方即XX省委省政府提出变更祈求，假设提出的是规定添加不用登录网页直接通过“政府公文审批及工作通告”应用程序即可向网内顾客发送邮件，并根据不一样层级顾客的权限显示网内在线顾客。则大连理工大学需根据协议和变更祈求进行变更评估，并提出协议修改提议，确定修改方略。对目前同需方，此处略。(不过政府的项目，即便政府违约了供方也得忍着，一般的企业应当就当作什么也没发生过。不过大工校长跟省长貌似平级吧，状况也许会有点不一样样。当然政府的项目会不会交给学校来做我也不是很清晰。)在产品的开发测试结束后向XX省委省政府提交产品，通过审查后正式提交给XX省委省政府。最终相方签字承认，告知有关各方。根据协议中的维护需求，制定维护需求记录。1.2.4协议终止过程同需方，此处略。大连理工大学软件学院内部确定任务范围，使有关各方有效的配合。详细任务分解在第四部分任务分解中会有详细论述。乙方：大连理工大学协议形式：技术协议供应的软件：乙方为甲方提供所需的“政府公文审批及工作通告”应用程序提供的服务：乙方为甲方提供所需的平常维护和服务器管理。同步对甲方顾客提供使用教学。提供的文档：乙方在交付软件时提供详细的软件规格阐明书和使用文档。安装服务：乙方为甲方提供软件的安装。公文处理：乙方负责将甲方提供的公文资料加载入系统并进行分类维护协议：当甲方在使用该产品时，在正常操作的状况下出现BUG或系统错误，乙方免费为甲方提供修复服务以保障软件的正常使用。当由于甲方的错误使用等非软件原因导致出现故障，乙方同样提供修复服务。由于甲方拥有该软件的源代码所有权，因此甲方需要承担部分维修和深入开发的责任。当软件需要新的功能拓展或改版升级时，由双方共同协商决定。该软件是由甲方向乙方定制，甲方拥有该软件的版权，乙方不能将该软件的任何版本卖个其他客户。软件提交时，项目源代码的所有权自动移交到甲方，乙方不得私自对源代码进行修改。乙方为甲方安装软件和进行员工培训时，需要由甲方提供住宿和膳食，乙方在规定期间内完毕任务。甲方要保证安装软件的硬件设备和协议初始规定一致，乙方只保证软件和规定的硬件兼容。由任何一方的单方面原因导致的延期产生的费用，由该方面支付。乙方开发软件过程中，甲方通过人员协同乙方进行开发。该人员重要参与项目的规划设计和需求分析，阶段性验收和总体测试。当项目出现需求变更时，对乙方进行详细的论述阐明。乙方不负责这些人员提供食宿和联3月15日，乙方为甲方安装所需套数的软件。3月15日至3月31日甲方代表对产品进行验收测试，并根据需求在4月30日前对产品提出改正祈求。测试通过后，双方带白哦进行软件交付签字。乙方对甲方进行软件使用培训。乙方在开发过程中必须遵守ISO12207有关软件生命周期和文档的原则。甲乙双方前四个月每月初进行一次进展会议，后三个月每两周周末进行进展会议。会议内容为乙方向甲方提供最新进度的掩饰和下一阶段的工作安排和计划。甲方根据演示提出对应的整改意见，并对下一步工作进行提出意见和提议。详细时间表见项目进度。此处略。软件总价为230W。协议签订后，甲方向乙方支付50万元定金。项目的第三个月，乙方按计划时间表完毕需求分析、系统分析、设计和完毕系统的基本框架后，甲方向乙方支付80万元。该系统完毕后，甲方进行验收测试，在签字验收后完毕后，甲方向乙方支付全款。由任何一方的过错导致出现损失后的赔偿由双方协商决定。甲甲乙第二部分生存期确定该项目的生存期模型按如下环节进行分析：评审、分析项目的特性；“政府公文审批及工作通告”应用程序波及到非常敏感的政府机密事务，因此很强调产品的性能和安全性。需保障产品能保持稳定运行，不会由于一定数量的顾客同步处理公文等操作时挂机，以致宝贵的消息或告知无法及时传达。同步需保证对于计算机操作不是十分熟识的政府官员的错误操作不会导致严重后果。此外需保证产品的安全性，使非内部顾客无法登录或盗取网内信综上所述该项目性能安全性为主，可操作性次之，界面美观度最末。虽然操作性的重要性不及安全性，但对于习惯了那种生活的领导们，简朴以便的操虽然项目的需求也许会因领导“挑剔”的口味而一再变化，不过大体的需求是明确的。并且又考虑到项目安全性能的首要规定，以V模型为基础的生存期最为合适。同步参杂增量模型生存期的某些特点以应对也许会随时添加的功增加功能该生存期模型将V模型除最终的项目规划和验收测试以外的过程做一复制，套用增量模型在首先完毕基本功能的基础上增长功能。第三部分需求管理XX省委省政府提出需求如下：设计开发、安装调试并后期维护满足需求的“政府公文审批及工作通告”应用程序。需要该程序为桌面应用程序，进入程序后需要弹出办公界面，该办公界面需与计算机自身系统分离，不得覆盖，具有独立窗口。内部需有公文处理、邮箱、事务表、内嵌Office、新闻速览、视频会议室6个重要功能，每个功能需在办公界面中有独立的快捷方式。每个功能的详细公文处理：1.正式公文的公布与接受4.公文的内容立案，内容立案需祛除盖章和签名并打水印，只且可读可删除储存在该顾客ID下的公文，不可写不可5.公文可以按已通过，已驳回，待审批，新公文，垃圾箱分类6.公文真伪检查，根据公文号唯一性等根据判断收到的公文真伪网内邮箱：1.实现网内按顾客ID分派邮箱名，且可以并只可以在网内发事务表：1.新建、删除、修改、查看事务表2.事务届时提醒，提醒时间可自行设定。到设定的提醒时间3.可以将事务表内容以桌面小工具的形式放在办公页面上显示内嵌Office:在办公界面下也可以被使用新闻速览：可以通过该功能浏览各大门户网站的头版头条或有关新闻。同3.1.1需求规格·需求规格阐明书(简略版)功能规格：公文处理(公布，接受，分类，审批，电子盖章签名，提交草案，修改意见答复，水印图片公文立案，真伪检查);邮箱(网内，新邮件弹窗提醒);事务表(增删改查，事务提醒，桌面小工具);内嵌Office;新闻速览(门户网站链接，电子报阅览);视频会议室。性能需求：保证政府内部所有人员同步登录服务器时也不会因处理的信息量过大而导致系统瘫痪。另必须保证系统的安全性，可以禁得住一般的黑客袭击和内部作假。对账户有足够的保护措施以防账户被盗。操作简朴明了，提醒明显，轻易上手，界面整实现约束：公文处理、邮箱、事务表、内嵌Office、新闻速览、视频会议室质量描述：如需求所述的足够顾客承载量；可靠的系统安全性；操作乙方(供方):大连理工大学3.1.2需求变更管理假设XX省委省政府向大连理工大学提出如下需求变更：在办公界面做一种可收缩的列表，显示目前系统在线的人员，以便政府内部人员联络。并且可以通过该列表直接与列表中任意顾客进行邮件联络，不用申请日期：9月6日修改内容：增长功能“可收缩的在线人员显示列表”,可之间与表中顾客验证日期：9月7日4.1任务清单1.1.6单元测试1.2邮箱1.2.2联络人功能1.2.3添加附件1.2.4新邮件弹窗提醒1.2.7单元测试1.3事务表1.3.2事务表的提醒功能1.3.3界面并做成桌面小工具1.3.4单元测试1.4内嵌Office1.4.2单元测试1.5新闻速览1.5.2党报、主流报纸、及当地报纸的电子阅览1.5.3界面1.5.4单元测试1.6视频会议室1.6.1多人视频功能1.6.2界面1.6.3单元测试1.7办公界面1.7.2后台数据传播1.协议签订1.1需求分析汇报&项目初步规划1.2项目提议书2.计划编制2.1时间表3.确认计划1.需求开发2.需求管理2.1需求规格阐明书3.系统测试计划编制1.方略确定2.开发标精确定(详细分派方式见任务清单)3.架构设计(详细分派方式见任务清单)4.集成测试计划编制1.接口设计(详细分派方式见任务清单)2.模块设计(详细分派方式见任务清单)3.单元测试计划编制1.编码(详细分派方式见任务清单)2.代码复核3.单元测试1.集成测试2.系统测试3.测试总额4.缺陷跟踪5.手册编写5.1直接成本成本估算的措施有1.代码行、功能点、对象点。2.类比(自顶向下)估在这个项目中我们重要采用功能点估算法，同步融合进入其他的估算措施进行验证。用系统的功能数量来测量其规模，与实现产品所使用的语言和技术5.1.1基本公式UFC:未调整功能点计数TCF:技术复杂度因子TCF=0.65+0.01(sum(Fi)):Fi:0-5,复杂度权重原因项简朴一般复杂外部输入346外部输出457外部查询346外部文献57内部文献7本项目的功能点计算：功能点项简朴一般复杂外部输入外部输出外部查询外部文献内部文献总计技术复杂度因子可靠的备份和恢复数据通信分布式函数性能大量使用的配置联机数据输入在线升级复杂界面复杂数据处理安装简易性多重站点易于修改TCF=0.65+0.0.1*(5+4+3+2+1+5+3+2+2+3+5+4+3+3)功能点计算：TCF=1.1.人月数计算：在本项目中，根据以往的经验使用经验导出成本模型(面向FP驱动的)中的Kemerer模型E=60.62×7.728×10-⁸FP³。月)开发(工作量)规模：Scale(Dev)220.03(单位：人月)管理、质量(工作量)规模：Scale(Mgn)=a*Scale(Dev)=220.03*20%=a:比例系数：例如：20%--25%直接成本=规模*人力成本参数=264.03*0.15=40万元人力成本参数=1500/人月(由于校内开发，成本比较低)5.2间接成本间接成本=规模*人力成本参数*间接成本系数(间接成本系数=1.5—3)本例中间接成本=220.03*0.15*1.5=60万元。估算成本=直接成本+间接成本=40+60=100万元由于基础数据局限性，缺乏经验的估算人员，签约前后不连贯，低劣的推测技术，估算对需求的敏感性等一系列原因，也许会引起估算的误差。对此项目的人月数定义考虑误差如下估算：220个人月+40-25+15人月：需求变更-15人月：学生的晚上时间的运用最佳状况：195人月。计划状况：220人月。最坏状况：260人月。项目进度管理是指在项目实行过程中，对各阶段的进展程度和项目最终完毕的期限所进行的管理。是在规定的时间内，确定出合理且经济的进度计划(包括多级管理的子计划),在执行该计划的过程中，常常要检查实际进度与否按计划规定进行，若出现偏差，便要及时找出原因，采用必要的补救措施或调整、修改原计划，直至项目完毕。其目的是保证项目能在满足其时间约束条项目进度管理是根据工程项目的进度目的，编制经济合理的进度计划，并据以检查工程项目进度计划的执行状况，若发现实际执行状况与计划进度不一致，就及时分析原因，并采用必要的措施对原工程进度计划进行调整或修正的过程。工程项目进度管理的目的就是为了实现最优工期，多快好省地完毕任项目进度管理是项目管理的一种重要方面，它与项目投资管理、项目质量管理等同为项目管理的重要构成部分。它是保证项目准期完毕或合理安排资源供应，节省工程成本的重要措施之一。6.1活动定义1.1需求分析汇报&项目初步规划2.1项目提议书3.1协议草案2.1时间表1.1需求探索2.1需求规格阐明书1.方略确定2.开发标精确定(详细分派方式见任务清单)3.架构设计(详细分派方式见任务清单)3.集成测试计划编制1.接口设计(详细分派方式见任务清单)2.模块设计(详细分派方式见任务清单)3.单元测试计划编制1.编码(详细分派方式见任务清单)2.代码复核3.单元测试2.系统测试3.测试总额4.缺陷跟踪5.手册编写描述任务时间/月项目规划A1需求分析B2总体设计C1详细设计D2编码E3测试F3甘特图开始时间持续时间1项目规划2需求分析3456A两个月E三个月FB个月C关键途径是决定项目完毕的最短时间，关键途径上的任何任务都是关键任务，关键途径上的任何活动延迟，都会导致整个项目完毕时间的延迟.在这个项目中首先按照时间次序计算最早开始时间和最早完毕时间，然后按照逆时间次序计算最晚开始时间和最晚结束时间。从而得出关键途径是：开始-》需求分析-》详细设计-》编码-》测试。6.3进度执行与优化在项目的进行过程中可以通过1、分解关键任务2、给任务增长资源3、缩减关键任务的工期4、重叠或延迟链接任务5、设置日历增长工作时间6、通过度派加班工时来缩短关键任务来到达缩减项目工期的目的。6.4工具使用在整个项目中将使用Microsoft的项目管理软件产品microsoftproject2010来进行项目的管理第七部分质量计划7.1.1项目经理的职责1.评审质量计划。2.与质量保证人员一起协商不符合项问题的纠正措施，并安排资源实行纠正措施。3.定期或事件驱动地评审质量保证活动和成果。7.1.2质量保证人员的职责1.负责项目实行过程中对项目实行状况进行监督，包括对项目实行过程和工作产品进行监督检查。2.实行项目组组员的质量保证培训。3.制定质量保证计划。4.按计划实行审计活动，根据质量保证计划执行评审/审计，并记录执行中发现的不符合项。5.对不符合问题提交不符合项汇报，跟踪并验证纠正措施的执行状况。6.对项目内不能处理的不符合项问超；向高层管理提交汇报。7.向项目经理汇报项目质量工作状况和质量度量成果。8.定期向项目组汇报质量活动的成果。8.制定质量保证的过程改善计划，记录过程数据。7.1.3质量目的1)基于需求的测试覆盖率为100%。2)功能测试完善3)每个阶段评审中发现的问题都已经处理或得到合适处理。4)产品公布时不存在严重问题以及以上的缺陷。5)严格满足协议的规定和规格6)顾客领导满意7.1.4质量方略1.控制产品的质量，及时纠正缺陷2应当尤其注意项目工作产品质量的初期评审工作，元论是质量保证还是质量控制，采用的方略都是初期防止和初期排除缺陷。3将质量贯彻到平常的项目进展过程中；7.2软件质量保证活动7.2.1审计审计(Audit)是对过程或者产品的一次独立评估。将审核的主体与为该主体此前建立的一组规程和原则进行比较目的是保证真正的遵照了这一种过程，产生了合适的文档和精确反应实际项目的汇报，可以预先规划的，也可以是临时决定的。目前讲本项目中的预先规划审计列出如下。在整个开发过程中，会根1.审计软件项目计划时间：计划结束原则：协议规定2.需求规划文档时间：需求制定原则：需求规格阐明3.总体设计文档时间：总体设计制定原则：软件项目计划4.详细设计文档时间：详细设计制定原则：软件项目计划5.编码规范时间：详细设计制定原则：软件项目计划6.产品代码时间：编码结束原则：编码规范7.测试文档时间：详细设计制定原则：企业质量规定8.顾客手册时间：产品提交之前原则：项目计划和需求将审计的成果编写审计汇报及时提交。如下是内容内容严重程度内容7.2.2过程评审项目严格按照组织定义的软件过程进行开发，过程评审的详细根据参照企业的过程规范，保证项目中的所有过程活动都在实行范围内。在每次评审之后，要对评审成果做出明确的决策并形成评审记录。评审可采用文献传阅、评审会等形式。质量保证人员负责对项目过程迸行监督，将发现的问题和处理状况在每周的例会上通报，对没有处理的问题迸行讨论，对不能处理的问题提交高级管理者处理。每个周末，进行一次配置管理审核，确认配置管理工作与否正常进行7.2.3问题汇报质量保证人员对于每次审计活动发现的不符合项，应当和项目经理协商不符合项的纠正措施并预定完毕日期，若和项目经理存在意见分歧，质量保证人员可以上报给高层管理者，由高层管理者决定最终的措施。同步，不符合项在项目周例会中汇报。对不符含项，质量保证人员耍在预定完毕日期内重新审计，验证不符合项的纠正状况，若超过预定完毕日期1周仍然有没处理的不符合项，质量保证人员上报给高级管理者，由高级管理者决定最终的措施。质量保证人员有独立的汇报途径，平常的汇报途径如下：1.将发现的问题告知项目经理，协调纠正措施。2.将项目组内不能协调的问题汇报给茼级管理者，由南级管理者协调处3.将平常工作和过程数据汇报给质量经理，由其统一搜集并进行记录。下面是本项目的测试大概计划，详细内容请查阅测试文档。1.基本测试单元测试集成测试系统测试测试工作安排测试准备工作测试用例设计2.系统测试设计版本兼容性测试性能测试恢复测试安全性测试压力测试7.4质量改善为了到达更好的质量，目前制定质量改善规定：1软件质量活动必须通过规划2.软件质量活动规划必须明文规定3.质量活动必须尽早开始4.质量小组必须独立存在5.应当通过训练6.必须有合适的经费本计划描述了有关“政府公文审批及工作告知”项目的软件配置管理组织构造以及贯穿本项目软件生命周期的由软件配置管理组织识别并定义的一系列的软件配置项的实践过程。计划软件配置管理工作必须在项目最开始时进行，和开发整个软件项目计划保持一致。软件配置管理计划，连同软件质量保证计划)和其他也许的特定约束计划都要符合本项目的软件项目计划。软件配置管理计划完毕之后应当由本项目的项目经理、SQA经理和其他有关人员进行审阅和同意。角色人员职责、工作范围管理者王颖(1)制定《配置管理计划》(2)创立和维护配置库负责人胡博(1)审批《配置管理计划》(2)审批重大的变更项目经理一丁峰洋审批某些配置项或基线的变更命名规范合用于过程文档、生存期中各阶段的计划、需求、设计、代码、测试、手册等文献。本项目文献命名规范由五个字段构成，从左到右依次为：企业、项目、类型、编号和版本号，如下图所示。这些字段用横线(-)分隔。企业：3个字符类型：最长5个字符编号：最长8位数字项目基线一览表号基线名称阐明创立/变更审批者布I:内部外部客户需求基线系统归于软件的客户需求，以及为满足客户需求，软件在实现上所应具有的处理功能需求获得同意设计基线架构造及各模块实现细节的设计详细设计获得同意【项目经理和项目组领导】I线得的代码完毕原始软件单元编码、并通过检查【项目经理和项目组领导】I测试基线为测试而公布软件【项目经理】I线为运行而公布系统8.3.3配置库号容阐明途径T12M需求管理3软件项目规划4软件项目跟踪与管理5软件配置管理6软件质量保证7件产品工程设计8源代码9目的代码测试公布9.1风险识别与评估9.1.1风险识别是试图通过系统化地确定对项目计划的威胁，识别已知9.1.2风险识别过程输入-》标识风险-》按照一定原则对风险排序-》制定风险表9.1.3根据“IT项目常常存在某些共同的风险源”我们根据以往经验制定了风险分析表。检查表法是运用检查表作为风险识别的工具，是根据风险要素建立软件项目的风险条目列表，列表中列出所有与风险原因有关的提问，可以使管理者集中识别常见的类型中的已知和可预测9.2风险规划9.3风险分析表通过对风险识别，风险评估，风险规划，我们制定了如下风险分析表。风险分析表1顾客抵制该系统。政府领导也许会由于某个细节的问题对整个系统产%力满足顾客提出的需求。2.界3.需求分析阶段派出专门的系统分析员去理解顾客的性格，爱好，工作习2期间，需求方更换领导。不一样的领导有不一样的需如更换领导将%件的可重用性。提高复用3客户的需求规格阐明。需求不明确，增长需蔓延，由于本软件是不太理解计算机的领导使用，变更需求也许性很%1.采用加班2.修改计划3.与客户商4.当出现影响重大的变更需求时与客户协调，这个4带来的限制。进度规定紧，协议金额%度.。5交付缩。需方存在紧缩交付期限的也许。导致%2.临3.调6项目信开发人员%1.注意项目团体的沟通，及时理解开发人员的动2.控制好项3.从其他的项4.从外部招人员验。由于本项目中的某些员工是刚刚招聘来的，也许会%有经验的程序员带着相对经验少的程序员发之前合适的计划。由于政府也许向下属单位推行该系统，导致使用%1.防患于未然，数据库上采用数据池的技术在，期效果。也许有某些技术达不到预期的效果，不能使需方满意。如访问速度，某些特效%懂得这种技术9.4风险控制1.实行和跟踪风险管理计划，保证风险计划的执行，评估削减风险的有2.针对一种预测的风险实际上与否发生了，保证针对某个风险而制定的团体是一定数量的个体组员组织的集合，包括自己组织的人、供应商、分包商、客户等为一种共同的目的工作，协调一致，快乐合作，最终开发出来高质量的产品。团体管理在整个项目的开发中具有十分重要通过度析我们采用项目型的组织构造。构造图如下项目经理职员职员职员总经理项目经理职员职员职员项目经理职员职员此构造的长处：1.项目经理对项目可以全权负责。可以根据项目需要随意调动项目组织的内部资源或者外部资源。2.项目型组织的目的单一，完全以项目为中心安排工作，决策的速度得以加紧，可以对客户的规定做出及时响应，项目团体精神得以充足发挥。有助于项目的顺利完毕。3.项目经理对项目组员有所有权利，项目组员只对项目经理负责，防止了职能型项目组织下项目组员处在多重领导、无所适从的局面，项目经理是项目的真正、唯一的领导者。4.组织构造简朴，易于操作。项目组员直接属于同一种部门，彼此之间的沟通交流简介、迅速，提高了沟通效率，同步也加紧了决策速度。此构造的缺陷：1.每一种项目型组织，资源不能共享，虽然某个项目的专用资源闲置，也无法应用于此外一种同步进行的类似项目，人员、设施、设备反复配2.企业里各个独立的项目型组织处在相对封闭的环境之中，企业的宏观政策、方针很难做到完全、真正的贯彻实行，也许会影响企业的长远发3.在项目完毕后来，项目型组织中的项目组员或者被拍到另一种项目中去，或者被解雇，对项目组员来说，缺乏一种事业上的持续性和安全4.项目之间处在一种条块分割状态，项目之间缺乏信息交流，不一样的项这个项目相比较软件企业开发的项目具有一定的由于该项目具有很大的临时性，项目组的组员也是从不一样的班级集中到一起。这样的特殊性使我们的这样的项目并不具有上面列出的2,3,4所示的缺陷。因此项目型组织构造利于团体的建设以及小组人员与任务的分派；此外该组织构造简朴易操作，并且目的单一，尤其合用于这种零碎的人员调度，同步很大程度上以便了组员间整体的沟通交流，加紧了决策速度。由于这个项目各模块间的耦合度较低，不需要小组间大量的信息共享；并且项目组内有着统一的交流方式(临时的网上讨论组),各项决策规定可以第一时间直接反应给项目组员。针对这是一种政府项目，顾客群体是不太理解计算机的政府官员，我们的界面应当做的也许的简朴实用，领导还也许随时提出某些需要用特定的技术才可以处理的需求。这样的项目构成构造，可以使我们在团体内部有稳定组员的同步，可以根据实时的需求，招聘某些有特殊技能的学生，使我们的项目可以到达锦上添花的效果。与此同步我们的项目的特殊性并没有减弱项目型的10.2团体沟通2.每周五的15:00-17:00召开项目周例会，3.及时提交问题汇报，问题可以通过网络提交，项目经理会及时获取问题第十一部分项目度量软件度量是对软件开发项目、过程及其产品进行数据定义、搜集以及分析的持续性定量化过程，目的在于对此加以理解、预测、评估、控制和改善。没有软件度量，就不能从软件开发的暗箱中跳将出来。通过软件度量可以改善软件开发过程，增进项目成功，开发高质量的软件产品。度量取向是软件开发诸多事项的横断面，包括顾客满意度度量、质量度量、项目度量、以及品牌资产度量、知识产权价值度量，等。度量取向要依托事实、数据、原理、法则；其措施是