软件项目管理 实验报告.pdf

《软件项目管理 实验报告.pdf》由会员分享，可在线阅读，更多相关《软件项目管理 实验报告.pdf（42页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件项目管理实验报告软件项目管理实验报告姓名：班级名称：指导教师：实验日期：序号11.0版本号修订内容全部内容教师评语软工四班2012-10-26目目录录一 合同.1二 可行性研究报告.2三 软件项目计划.10四 风险条目跟踪表.17五 进度计划风险列表.18六 开发进度月报.24七 开发任务卡.26八 个人开发进度月报.27九 项目开发进度月报.29十 项目进度周报.31十一 项目开发总结报告.32十二 模块开发卷宗.34一一 合同合同机票预订系统软件项目开发合同书甲方名称：武汉股权托管交易中心有限公司乙方名称：中电科长江数据股份有限公司项目名称：机票预订系统建设项目（第一包）合同编号:签订

2、日期:2011 年 10 月 24 日签订合同地点：武汉股权托管交易中心有限公司本合同由 武汉股权托管交易中心有限公司 (以下简称甲方)与 中电科长江数据股份有限公司（以下简称“乙方”）签订。本合同甲、乙双方必须遵守国家颁布的中华人民共和国合同法、中华人民共和国政府采购法，并各自履行应负的全部责任和义务。一、合同内容经甲乙双方充分协商，就武汉股权托管交易中心交易系统建设项目（第一包）达成如下合同条款：（一）本合同总金额为人民币：贰佰壹拾玖万捌仟元整（2198000.00 元）。上述合同价格是确定不变的。任何合同价格之变更须经甲方、乙方签订修正合同方为有效。由于项目工期紧张，施工内容较多，存在招

3、标文件要求与实际情况不相符的情况，需甲乙双方进行协商，在不超过合同额 8%的范围内进行浮动，系统平台硬件按甲方要求于 11 月 10 日前全部正常开通并运行。（二）供货期：1.精密空调确认中标后 20 天内到货；2.服务器确认中标后 7 天内到货；3.网络设备确认中标后 7 天内到货；4.UPS 设备确认中标后 20 天内到货；5.其他设备可根据现场实施情况调配；6.所有设备和材料规格、性能不能低于投标书的要求，经甲方验收签字后1进行施工。二、付款方式1、合同签订后，7 个工作日内，甲方凭乙方出具的普通商业发票支付合同额 40%，即人民币：捌拾柒万玖仟贰佰元整(879200.00 元)；2、项

4、目完成并通过验收后，甲方凭乙方出具的普通商业发票支付合同额55%，即人民币：壹佰贰拾万零捌仟玖佰玖拾元整（1208990.00 元）；3、项目验收合格后一年，甲方凭乙方出具的普通商业发票支付合同额 5%，即壹拾万零玖仟玖佰元整（109900.00 元）；三、合同范围1、甲方同意将项目的系统集成、及硬件设备的采购委托乙方，乙方同意承接合同的；2、合同设备的技术指标、系统集成要求以及乙方对设备技术保证、集成需求响应应符合招标文件中的全部规定；四、双方职责乙方职责1、乙方应向甲方提供系统建设的正确具体设计方案和实施方案，负责对系统进行安装、调试；2、乙方将在本系统中投入技术精湛、业务熟悉、经验丰富的

5、技术人员队伍，并保证全体人员具有合理的配备和技术构成；3、乙方负责购买合同中甲方所需要的设备，合同执行期间，乙方保证基于合同附件的原始数据的设备构造是正确无误的；4、乙方保证所提供的技术资料及技术图纸完整、清楚、正确、与合同相关附件相符；甲方职责1.甲方应协助乙方在甲方所在地的项目实施；2.甲方负责安排设备安装场地及进入场地的通道；3.甲方应指定专人全权负责本项目的执行；五、技术要求和验收1、本项目的实施须按照合同签订后所进行的项目会议中所确定的日程进行，甲乙双方共同对整个项目进度负责；2、在合同生效后甲乙双方各指派一名代表，全权负责整个合同执行过程中2的一切事宜。所有有关甲乙双方的对口问题，

6、在双方全权代表正式通过并签字同意后，方才有效。甲乙双方皆不对未经签字的事宜负责。双方在更换全权代表时，须以正式书面形式并经主管负责人签字后通知双方，项目详细安排应通过友好协商后决定。如出现任何问题及争端，双方应就工作及出现之问题加以记录。并保留书面记录及签字；3、乙方所提供的技术方案必须符合甲方的实际情况，并保证所提供的设备需符合本合同书附件规定的技术标准；4、乙方对所有合同设备需在甲方安装地点进行开箱检验。如在开箱检验时发现有任何缺损或与相关的设备清单及技术资料不符，双方应对此作详细记录并签字，甲方有权凭此向乙方提出调换或补发。乙方提交给甲方相关之生产厂家产品质量合格证及技术性能指标说明书；

7、5、网络系统测试：甲乙双方根据测试文件之规定，进行设备系统测试，设备系统测试完成后，应签署“系统设备测试验收书”，系统设备测试验收书签署后，系统投入试运行；6、机房测试：对 UPS 主机、电池、供电线路、综合布线进行测试；7、精密空调测试；8、消防、监控、门禁测试。9、系统运行半年后，甲方指定组成专家验收团进行验收。六、服务与承诺1、乙方对所提供的设备提供三年的免费技术支持和升级服务；2、乙方安排 1 名驻守人员，在项目验收后半年内，负责项目维护相关工作；其后根据具体情况，由甲方提出是否继续延长驻守时间，最长时间不超过一年。3、乙方在三年内提供每周定期回访，就设备使用情况进行定期检查；4、乙方

8、向甲方提供 7*24 小时热线电话服务，并通过多种形式实现技术咨询和故障报修。5、当甲方发生硬件故障时，乙方需要 2 小时内到达现场，4 小时内解决故障，对发生故障损坏而无法在 4 小时内修复的服务器和网络设备等其它设备应在6 小时内提供同品牌同型号或性能高于故障件的替换件，确保 6 小时后甲方的业务不受到受损设备的影响。6、乙方须制订备品、备件及消耗品清单，承诺至少免费提供设备正常运行3三年所需的备品备件、易损品；七、培训1、为保证甲方能在运行中良好工作，乙方应为甲方培训1-2 名质量合格的维护工作人员、技术人员、管理人员。2、一方提供完整的技术操作和配置说明手册，用于培训甲方人员。3、培训

9、过程：乙方派技术人员免费培训甲方技术人员，使甲方技术人员熟练掌握设备的性能和一般操作维护技术，甲方委派人员与乙方技术人员一同参与安装、调试。4、乙方全力和毫无保留地对甲方系统运行维护人员进行技术指导和培训，以使他们掌握系统的使用和维护。5、乙方到现场进行设备安装工作，同时向甲方提供现场应用系统安装讲解服务，使甲方对系统的结构和功能设置有全面的认识。八、不可抗力1、合同签订任何一方国战争、火灾、水灾、台风、交通事故、地震等原因致无法履行其合同义务时，本合同执行时程将延长与上述事故持续时间相等之日数。2、因不可抗力致使无法发行义务一方应立即以书面通知对方，并于不可抗力发生后十四天内，以航空挂号信函

10、寄送当地主管机构核发之证明以证该不可抗力之发生。3、如不可抗力影响合同执行超过180 天，双方应就合同的进一步执行与否进行磋商并达成一致。九、争议的解决在执行合同过程中发生之任何纠纷需通过双方协商解决，如此纠纷未能得到解决，则需提交诉讼解决，双方约定，诉讼由武汉本地法院管辖。十、违约责任1、如乙方不能按期交付设备，甲方有权扣留全部履约保证金，同时乙方应向甲方支付合同总价 1%的违约金。2、乙方逾期交付设备的，每逾期1 天，乙方向甲方偿付逾期交货部分设备总额的 5的滞纳金。如乙方逾期交货达 5 天，甲方有权解除合同，解除合同的通知自到达乙方时生效。3、乙方所交付的设备品种、型号、规格不符合合同规

11、定的，甲方有权拒收。4甲方拒收的，乙方应向甲方支付 5的违约金。4、在乙方承诺的或国家规定的质量保证期内（取两者中最长的期限），如经乙方两次维修或更换、设备仍不能达到合同约定的质量标准，甲方有权退货，乙方应退回全部货款，并按第 3 款处理，同时乙方还须赔偿甲方因此遭受的损失。5、乙方未按本合同的规定和“服务承诺”售后服务的，应按合同总价款的5向甲方承担违约责任。6、乙方在承担上述1-5 款一项或多项违约责任后，仍应继续履行合同规定的义务（甲方解除合同的除外）。甲方未能及时追究乙方的任何一项违约责任并不表明甲方放弃追究乙方该项或其他违约责任。7、甲方正当理由逾期一周未付，每逾期1 天，按延误付款

12、金额向乙方支付5的滞纳金。十一、其它1、本合同用一式共伍份。甲乙双方各执贰份，湖北省招投标工程公司备案壹份，均具有同等法律效力。本合同自双方代表签字盖公章之日起生效。2、本合同书附件包括：合同设备清单售后服务承诺书3、上述合同附件均为本合同不可分割之部分，并与本合同具有同等法律效力。4、所有有关本合同条款之修改、补充、变更经双方代表以书面形式制成并签字盖公章后均为本合同不可分割，并具有本合同同等之法律效力。5、双方在执行合同过程中之联系须用书面形式制成。5签字页甲方（章）乙方（章）地址：地址：委托代表人：项目负责人：日期：委托代表人：项目负责人：日期：1二二 可行性研究报告可行性研究报告1 1

13、 引言引言1.11.1 编写目的编写目的为了以最小的代价在最短的时间内确定机票预订系统项目是否值得去开发，其中的关键和技术难点是什么，问题能否得到解决，怎样达到目的？我们编写了可行性报告以对这些问题进行分析。除此之外，经过对此项目进行详细调查研究，我们初步拟定了系统实现报告，对软件开发中将要面临的问题及其解决方案进行初步设计及合理安排。明确开发风险及其所带来的经济效益。以便于中小规模工厂的仓库管理人员阅读及理解整个项目。1.21.2 背景背景a.机票管理系统b.开发软件名称：机票预订系统项目提出者：软件工程小明项目开发者：小明项目使用者：中电科长江数据股份有限公司c.本系统将由两部分组成：置于

14、定票点的前台客户端应用程序，以及置于航空公司的数据库服务器。1.31.3 定义定义旅行社1.登录系统：在执行所有的操作之前，必须登录系统。这是所有的操作的前提。2.注册：新用户必须登录系统进行注册，然后才能登录系统进行相关操作。3.查询：旅行社查询车票信息。4.订票：旅客登陆系统后可以进行订票操作。旅客1.登录系统：在进行所有的操作之前，必须登录系统。这是所有的操作的前提。2.注册：新用户必须进行注册。23.修改个人信息：旅客可在登录系统后对个人信息进行修改。4.订票：旅客登陆系统后可以进行订票操作。5.查询：旅客登陆系统后进行订票操作。1.41.4 参考资料参考资料【1】张海涛，软件工程导论

15、，清华大学出版社，2008.【2】麻志毅，面向对象分析与设计，机械工业出版社，2008.【3】王珊编，数据库系统概论（第四版）高等教育出版社，20082 2 可行性研究的前提可行性研究的前提2.12.1 要求要求A功能：（1）在系统中，可以通过航班号、目的地、起飞日期、目的地等查询航班，输出该次航班的起飞时间和所剩票数和票得价格。（2）预订成功后，旅客交付了预定金之后，系统打印出取票通知和账单给旅客。（3）在飞机起飞之前一天，根据乘客的需求打印出机票给旅客或者取消预订，并退还全额定金。B.性能：实时性和安全性是该系统最基本的要求，系统在保持高度实时性的同时，也要保持安全性。C.输出：机票信息准

16、确无误。D.输入：简捷，快速，实时。E.数据流图F.初步预计在 15 周内完成。2.22.2 目标目标借此系统减少人力与设备费用，提高处理速度，改进管理信息服务体系，提高工作人员利用率。2.3 2.3 条件、假定和限制条件、假定和限制A.硬件条件和限制：服务器为 Windows sql Server2000，并可在客户端服务器上使用；B.数据库：SQL Server2000；C.该系统要受硬件、软件、运行环境、开发环境、技术等因素的制约和限制；3D.建议该系统最低的使用寿命为 2 年，在 2012 年 12 月之前投入使用；E.法律方面可保证所用的一切信息皆来自正规渠道，保证信息的合法性，在法

17、律方面完全可行2.42.4 进行可行性研究的方法进行可行性研究的方法I 技术可行性此系统采用了成熟且完善的 Visual Studio 2010 和 SQL Server2008 软件开发工具来进行后台数据库的管理、操作和维护。该软件功能强大，可用性强，完全可以满足我们开发项目的要求。经济可行性随着我国经济的发展，计算机技术不断更新，传统机票预订方式已经不能满足人们的需要，机票预订系统的开发具有客观的经济效益。并且，此项目开发成本低，占用资源少，在经济方面可行。操作可行性本系统设计思路清晰，操作简捷，具有良好的用户界面，和较为完善的异常处理机制及信息处理机制，一般工作人员稍加培训即可使用。在操

18、作方面可行。2.52.5 评价尺度评价尺度当 5 亿用户同时使用该系统时，仍能正常运行。系统响应时间短，并且界面简洁大方。同时简单易操作，安全性良好3 3 对现有系统的分析对现有系统的分析3.13.1 处理流程和数据流程处理流程和数据流程4订票事务订票系统程序旅客信息主文件票务信息报告生成程序系统详细流程 1)登录功能要求必须具备合法身份且知道密码的人才能有资格登录到该系统，保证系统的安全。2)机票的预订功能是旅客通过网站选择需要的机票后，预订机票，服务器更新数据，打印机票。3)查询功能是旅客登陆网站，查询机票的相关信息并显示。3.23.2 工作负荷工作负荷手工方式工作。3.33.3 费用开支

19、费用开支人员招聘、工作办公室安排等。3.43.4 人员人员记录员：5 个3.53.5 设备设备打印机。3.63.6 局限性局限性经济的不断发展有效地带动交通业和旅游业务的不断扩大,特别是航空售票和订票的信息管理日异复杂,，以前的手工方式已经难以满足快节奏,高效率的现代生活需求,，有时乘客由于不了解航空公司机票销售的信息,而不能在相应的时间内购到理想的机票。从而让费了大量的人力和物力资源,5有时也会给乘客在一定程度上带来损失，然而乘客通过旅行社,旅行社再根据乘客的相应的需求输入电脑系统,经过该系统为旅客安排航班，从而大大节省了人力和物力，因此开发这样一个机票预定系统就显得十分必要了。4 4 所建

20、议的系统所建议的系统4.14.1 对所建议系统的说明对所建议系统的说明将旅客信息（姓名、性别、工作单位、身份证号码、旅行时间、旅行目的地等相关信息）输入系统，系统为旅客安排航班，并打印出取票通知单和账单。在飞机起飞前一天，根据旅客的需求可以为旅客打印机票或者退票并退还全额的定金。4.24.2 处理流程和数据流程处理流程和数据流程4.1 处理流程订票事务订票系统程序旅客信息主文件票务信息报告生成程序4.2 数据流程旅行社旅客订票信息机 票机票预定系统旅客取票单取票单-机票预定系统基本系统模型顶层数据流图6订票单有效订票单航班信息检查订票单订票打 印取票单取票单和账单航班目录机票文件-机票预定系统

21、基本系统模型订票数据流图取票单有效取票单缴费信息机票检查取票单交费账单打印机票-机票预定系统基本系统模型取票数据流图4.34.3 改进之处改进之处较好的人机交互界面，运行效率高，出错率低，同时易维护。4.44.4 影响影响4.4.1.4.4.1.对设备的影响对设备的影响设备采用一般的 PC 机即可，配置一台打印机。4.4.2.4.4.2.对软件的影响对软件的影响现有软件由于无法满足现有的需求，故将废置不用。4.4.3.4.4.3.对用户单位机构的影响对用户单位机构的影响人机交互界面，更加人性化，能够提供更多的功能。可以在订票是，查询航班，安排旅客满足的航班。74.4.4.4.4.4.对系统运行

22、过程的影响对系统运行过程的影响系统建议在 windows xp 操作系统下运行。4.4.5.4.4.5.对开发的影响对开发的影响A开发过程中需要用户大力支持。一个新系统的开发，必然会减少用户们的工作量；4.4.6.4.4.6.对地点和设施的影响对地点和设施的影响对原有地点设施无影响4.4.7.4.4.7.对经费开支的影响对经费开支的影响因为此系统操作简单，除支付开发人员费用以外，每年只需支付少量的设备维护费用，对支出要求较低4.54.5 技术条件方面的可能性技术条件方面的可能性该系统规模较小，使用现存的 C 或者 C+技术完全可以解决。5 5 可选择的其他系统方案可选择的其他系统方案无。6 6

23、投资及效益分析投资及效益分析6.16.1 支出支出6.1.1 基本建设投资基建工资主要为开发人员的工资。开发周期为 15 周，开发人员为 4 人。每人每月工资为 5000 元，则所有开发人员的工资支出为 8 万元。6.1.2 其他一次性支出其他一次支出包括硬件设备费用、购置材料费用、及其他费用。其中，硬件购置费用为 4 台计算机为 30000，外购开发工具及联网 20000，其他费用 20000，共计 7 万元6.1.3 非一次性支出包括交通费，设备维护费，及开发人员福利。共计 5 万元。6.26.2 收益收益6.2.1 一次性收益旅客旅游收益。6.2.2 非一次性收益8订票效率增加，旅客人数

24、也相应增加，带来更多的收益。6.2.3 不可定量的收益未来外出旅游的人数会不断增加，会带来不可定量的收益。6.36.3 收益收益/投资比投资比若以五年为周期，原有的手工方式，收益/投资比会增加 5-6 倍。6.46.4 投资回收周期投资回收周期由一年内即可完成投资回收。6.56.5 敏感性分析敏感性分析该系统操作简单，开发完善，预计使用年限为 5 年，对硬件有较低要求。故只需要在操作时注意保护硬件设备即可。7 7 社会因素方面的可能性社会因素方面的可能性7.1.7.1.法律方面的可行性法律方面的可行性 本系统可保证所利用到的一切资源来源皆合法，不涉及任何侵权行为，更不设计合同纠纷，法律方面完全

25、可行。7.2.7.2.使用方面的可行性使用方面的可行性 系统对操作人员要求较低，只需具备基础的职业素质及操作技能即可。操作简单，对人员无太大要求。8 8 结论结论根据目前的实力，该项目能够被实现，并在未来很好的运行，可以开始实施项目。9三 软件项目计划1.1.引言引言1.11.1 编写目的编写目的为了以最小的代价在最短的时间内确定机票预订系统项目是否值得去开发，其中的关键和技术难点是什么，问题能否得到解决，怎样达到目的？我们编写了可行性报告以对这些问题进行分析。除此之外，经过对此项目进行详细调查研究，我们初步拟定了系统实现报告，对软件开发中将要面临的问题及其解决方案进行初步设计及合理安排。明确

26、开发风险及其所带来的经济效益。以便于中小规模工厂的仓库管理人员阅读及理解整个项目。1.21.2 背景背景a.机票预订系统b.开发软件名称：机票预订系统项目提出者：软件工程小明项目开发者：小明项目使用者：中电科长江数据股份有限公司c.本项目采用客户机/服务器原理，客户端的程序是建立在 Windows XP系统上以 Microsoft Visual C+为开发软件的应用程序，服务器端采用 Linux 为操作系统的工作站。1.31.3 定义定义文档命名缩写规则DP Development Plan开发计划说明书SRI Software Requirement Instruction 软件需求说明书D

27、RI Data Requirement Instruction数据要求说明书GDI General Design Instruction概要设计说明书SDI Specific Design Instruction详细设计说明书DBDI DataBase Design Instruction数据库设计说明书UM User Manual用户手册OM Operation Manual操作手册10MD Module Development Volumns模块开发卷宗TP Test Plan测试计划TAR Test Analysis Report测试分析报告PDSR Project Developmen

28、t Summary Report项目开发总结报告1.41.4 参考资料参考资料软件项目管理 覃征 杨利英 高勇民 贺升平 编著 清华大学出版社。SQL Server 数据库基础教程计算机职业教育联盟清华大学出版社。2.2.项目概述项目概述2.12.1 工作内容工作内容本项目的开发中我们主要须进行分析项目的可行性代码编译123修改检测和执行。编写本项目的算法和第一周收集相关资料、客户背景、学习相关做项目的知识、写任务。第二周编写需求分析总体设计细节设计第三周实现编码、测试、编写用户手册、项目总结2.22.2 主要参加人员主要参加人员黄珊：工作认真负责，有一定组织和管理经验，为组长。张乐：有良好编

29、程能力和编写代码能力。陈君：细心、负责、全面，有良好编程能力，是一个良好的测试人员。梁丽:用户意识强,是个优秀界面设计师.2.32.3 产品产品2.3.1 程序程序名称统各项功能。实现基本功能2.3.2.文件文件的名称用文件的形式项目开发计划说明书 内容要点编制项目开发计划的目的是机票的预订和查询，打印机票和更新数据。机票预订系统.基于 Web使用 SQLServer2008 数据库实现系把对于在开发过程中各项工作的负责人员、开发进度、所需经以便根据本计划开展和费预算、所需软、硬件条件等问题作出的安排记载下来检查本项目的开 发工作。11文件的名称软件需求说明书内容要点软件需求说明书的编制是为使

30、之成为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解整个开发工作的基础。文件的名称数据要求说明书 内容要点数据 要求说明书的编制目的是为了向整个开发时期提供关于被处理数据的描述和数据采集要求的 技术信息。文件的名称说明书概要设计说明书 内容要点概要设计说明书又可称系统设计这里所说的系统是指程序系统。编制的目的是说明对程序 系统的设计考虑包括程序系统的基本处。流程、程序系统的组织结构、模块划分、功能分配、接口设计。运行设计、数据结构设计和出错处理设计等计提供基础。文件的名称详细设计说明书 内容要点详细设计说明书又可称程序设每个模块为程序的详细设计说明书。编制目的是说明一个软件系统各个

31、层次中的每一个程序或子程序的设计考虑文件的名称数据库设计说明书 内容要点数据库设计说明书的编制目的是对于设计中的数据库的所有标识、逻辑结构和物理结构作出具体的设计规定。文件的名称用户手册 内容要点用户手册的编制是要使用非专门术语的或潜在如何语言充分地描述该软件系统所具有的功能及基本的使用方法。使用户用户通过本手册能够了解该软件的用途并且能够确定在什么情况下使用它。文件的名称操作手册 内容要点操作手册的编制是为了向操作人员提供包括操作方法的细节。主要是指整个程序系该软件每一个运行的具体过程和有关知识文件的名称测试计划 内容要点这里所说的测试统的组装测试和确认测试。本文件的编制是为了提供一个对该软

32、件的测试计划包括对每项测试活动的内容、进度安排、设计考虑、测试数据的整理方法及评价准则。文件的名称测试分析报告 内容要点测试分析报告的编写是为了把组装测试和确认测试的结果、发现及分析写成文件加以记载。文件的名称开模块开发卷宗 内容要点模块开发卷宗是在模块开发过程中逐步编写出来的每完成一个模块或一组密切相关的模块的复审时编写一份12应该把所有的模块开发卷宗汇集在一起。编写的目的是记录和汇总低层次开发的进度和结果以便于对整个模块开发工作的管理和复审并为将来的维护提供非常有用的技术信息。文件的名称项目开发总结报告 内容要点项目开发总结报告的编制是为了总结本项目开发工作的经验的各个方面的评价。2.3.

33、3.服务计划提供以下服务：说明实际取得的开发结果以及对整个开发工作课堂培训：以讲课形式对客户进行培训，使其能够正确使用软件。免费咨询：客户可以在工作时间向技术人员提出问题并获得解答。技术支持：对于某些客户，采取上门指导的方式。软件维护：获取软件使用中的问题，提供补丁程序。升级通知：在软件新版本发布的时候，及时通知(Email 或邮寄信件)注册的用户，并提供试用版本。软件升级：对于注册用户，只需较少的费用即可升级到新的版本。2.3.4.非移交的产品1、项目开发计划2、源程序3、开发过程老的版本文档和程序。4、各自的心得评2.42.4 验收标准验收标准最后在交付客户之前进行小组内评审，代码编写符合

34、 HB6465 标准，与文档说明保持一致，代码书写风格统一，采用标准规范，没有下列错误：由于软件缺陷造成丢失数据，不符合设计要求，响应时间太长无法接受等问题。2.5 2.5 完成项目的最迟期限完成项目的最迟期限 交付日期 从 2012 年 4 月 5 日开始至 2012 年 10 月 5 日，完成对整个系统的可行性报告分析、需求分析说明书、开发计划说明说、系统设计书、项目测试、项目总结，对概念模型、存储模式、完整性控制、存取权限等进行了定义，对系统功能各模块进行了详细设计，定义了数据库总体结构、编码命名规范，并交付13用户。交付日期为 2012 年 10 月 10 日，延期交付日为 11 月

35、1 号。2.6 2.6 本计划的批准者和批准日期本计划的批准者和批准日期 本系统由客户提出，自 2012 年 4 月 15 号正式批准，审查者为小明，批准人为小明。3.3.实施计划实施计划3.13.1 工作任务的分解与人员分工工作任务的分解与人员分工黄珊：负责全局控制项目进度，项目质量，负责编写项目开发计划，项目开发总结报告，概要设计说明书，以及参与需求分析，概要设计，细节设计的编写。张乐：负责部分数据库设计，负责数据库设计说明书编写，总体设计说明书数据库设计说明书，以及参与需求分析，概要设计，细节设计的讨论。陈君：负责分析软件对于市场的需求和数据的要求，负责需求设计说明书和数据要求说明书的编

36、写，负责参与需求分析，概要设计，细节设计的编写梁丽：负责测试具体测试工作，负责测试计划，测试分析报告的编写以及参与需求分析，概要设计，细节设计的编写。3.23.2 接口人员接口人员a.负责本项目同用户的接口人员：梁丽。b负责本项目同本单位各管理机构的接口人员：黄珊。c.负责本项目和其他小组成员联系的接口人员：陈君。3.33.3 进度进度（1）文档进度文档名称负责人第一版完成时最 终 完 成 时间间4 月 11 号4 月 20 号4 月 27 号5 月 5 号5 月 7 号5 月 20 号5 月 20 号项目开发计划软件需求说明书数据需求说明书概要设计说明书总体设计说明书黄珊、陈君、张乐陈君、梁

37、丽张乐、黄珊、陈君黄珊张乐、陈君3 月 20 号4 月 12 号4 月 14 号4 月 18 号4 月 20 号4 月 26 号4 月 27 号数据库设计说明书张乐详细设计文档黄珊、张乐、陈君、梁丽14测试计划测试分析报告陈君、梁丽、张乐陈君、黄珊、梁丽4 月 29 号4 月 30 号5 月 1 号5 月 25 号5 月 31 号6 月 4 号项目开发总结报告黄珊（2）工作进度分析设计编码测试3.43.4 预算预算人员数量：4 人开发时间：4 个月资金预算设备预算起始时间3.204.184.264.29截止时间4.275.205.125.31负责人黄珊、张乐、陈君、梁丽黄珊、张乐、陈君张乐黄珊

38、、张乐、陈君300000 元100000 元3.53.5 关键问题关键问题（1）简历严格的审核制度，责任到人；（2）注意运用课堂学到的知识，边做边对照理论知识；（3）每个阶段开始前最好也要有计划及检查计划落实的措施；（4）开发过程对用户透明。4.4.支持条件支持条件4.14.1 计算机系统支持计算机系统支持运行环境硬件环境：服务器端/客户端：处理器：Inter PentiumIII 或者更高内存：512M硬盘空间：80G软件环境：15服务器端/客户端：操作系统：Windows XP网络协议：TCP/IP、HTTP浏览器：IE 6.0 或者以上4.24.2 需由用户承担的工作需由用户承担的工作4

39、.34.3 需由外单位提供的条件需由外单位提供的条件无。5.5.专题计划要点专题计划要点无。16四四 风险条目跟踪表风险条目跟踪表编者说明：对于中型以上的项目，风险控制的意义就犹为突出。要控制风险，就应该找到风险，并将风险记录下来，确定相关责任人，对于风险性高的、可能性大的还需要制订相关的应对措施。而最好的方法就是整理成为本模板中的表格，为每个潜在风险备个案。序列号确定日期撤消日期描述可能性影响危害值降低风险计划负责人截止日期注：可用0.1(极不可能)1.0(肯定发生)来表示 注：可用1(无甚么影响)10(有很深、很大的影响)来表示17五五 进度计划风险列表进度计划风险列表编者说明：准确来说，

40、本列表不是一个文档模板，而是一个参考文章。由于风险识别许多人都觉得无从入手，下面就是列出了与进度相关的风险条目，对于风险识别有很大的参考价值。1.1.最常见的进度计划风险最常见的进度计划风险1）功能无限蔓延；2）需求镀金或开发人员镀金；3）质量不定4）计划过于乐观5）设计欠佳6）银弹综合症7）研发导向开发8）人员薄弱9）签约商失败；10）研发人员与客户的磨擦。2.2.进度计划风险完整列表进度计划风险完整列表2.12.1 计划编制风险计划编制风险1）计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致；2）计划是优化的，是“最佳状态”；3）计划忽略了必要的任务；4）计划基于使用特定的小

41、组成员，而那个小组成员其实指望不上。5）在限定的时间内无法建成已定规模大小的产品；6）产品规模比估计的要大一些；7）工作量大于估算数；8）进度已经拖延的项目在重新评估时过于优化或忽视项目历史；9）过度的进度压力造成生产率下降；1810）目标日期提前，但没有相应地调整产品范围或可用资源；11）一个任务的延迟导致相关任务的连锁反应；12）涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。2.22.2 组织和管理组织和管理1）项目缺乏一个有凝聚力的最高领导人；2）由于前期乏力，项目长时间被搁置；3）解雇和削减开支导致项目小组能力下降；4）仅由管理层或市场人员进行技术决策，导致计划进度延长；

42、5）低效的项目组结构降低生产率；6）管理层审查/决策的周期比预期时间长；7）预算削减打乱项目计划；8）管理层做出了打击项目组织积极性的决定；9）非技术的第三方的工作比预期延长（如审批，采购等）；10）计划性太差，无法适应期望的开发速度；11）项目计划由于压力而放弃，导致开发混乱、低效；12）管理层强调英雄主义，而忽视客观确切的状态报告，这会降低发现和改正问题的能力。2.32.3 开发环境开发环境1）设施没有及时到位；2）设施到位，但不配套；3）设施拥挤、杂乱或者破损；4）开发工具未能及时到位；5）开发工具不如期望那样有效，开发人员需要时间创建工作环境或切换新的工具；6）开发工具的选择不是基于技

43、术需求，不能提供计划要求的性能；7）新开发工具的学习期比预期的长，内容繁多。2.42.4 最终用户最终用户1）最终用户坚持新的需求；2）最终用户对于最后交付的产品不满意，要求重新设计和重做；193）最终用户不买进项目产品，无法提供后续支持；4）最终用户的意见未被采纳，造成产品最终无法满足用户期望，而必须重做。2.52.5 客户客户1）客户坚持新的需求；2）客户对规划、原型和规格的审核/决策周期比预期长；3）客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和耗时的重复；4）客户答复的时间比预期长（如回答需求中需澄清的问题）；5）客户坚持技术决策而导致进度计划延长；6）客户对开发进度管

44、理过细，导致实际进展变慢；7）客户提供的组件无法与开发的产品匹配，导致额外的设计和集成工作；8）客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作；9）客户要求的支持工具和环境不兼容、性能差或者功能不完善，导致生产率降低；10）客户不接受交付的软件，尽管它满足了所有的规格；11）客户期望的开发速度是开发人员无法达到的。2.62.6 承包商承包商1）承包商没有按承诺交付组件；2）承包商递交的组件质量低下无法接收，必须花时间改进质量；3）承包商没有买进项目开发需要的工具，进而无法提供需要的性能水平。2.72.7 需求需求1）需求已经成为项目基准，但变化还在继续；2）

45、需求定义欠佳，而进一步的定义会扩展项目范畴；3）添加额外的需求；4）产品定义含混的部分比预期需要更多的时间。202.82.8 产品产品1）错误发生率高的模块需要比预期更多的测试、设计和实现工作；2）校正质量低下不可接受的产品，需要比预期更多的测试、设计和实现工作。3）在一个或多上新兴领域推广计算机技术使得计划进度的延长不可预期；4）由于软件功能的错误，需要重新设计和实现；5）开发额外不需要的功能（镀金）延长了计划进度；6）要满足产品规格与速度要求，需比预期更多时间，包括重新设计和实现的时间；7）严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；8）要求与其他系统、复杂系统或不受

46、本项目控制的系统相连，导致无法预料的设计、实现和测试工作。9）要求在不同操作系统下运行将花费比预期更长的时间；10）在不熟悉或未经检验的软（硬）件环境中运行产生未预料的问题；11）开发一种对组织全新的模块将比预期花费更长的时间；12）依赖正在开发中的技术将延长计划进度。2.92.9 外部环境外部环境1）产品依赖政府规章，而规章的改变将是不可预期的；2）产品依赖草拟中的技术标准，而最后的标准将是不可预期的。2.102.10 人员人员1）招聘人员所花时间比预期的长；2）作为先决条件的任务不能按时完成（如培训、其它项目）；3）开发人员和管理层之间关系不佳导致决策缓慢，影响全局；4）项目组成员没有全身

47、心投入项目，进而无法达到需要的产品性能水平；5）缺乏激励措施，士气低下，降低了生产能力；6）缺乏必要的规范，增加了工作失误与重复工作；217）某些人需要更多时间适应不熟悉的软件工具和环境、硬件环境、编程语言；8）项目结束前，合同制人员离开团队，或雇员辞职；9）项目后期加入新的开发人员，额外的培训和沟通降低现有成员的效率；10）项目组成员不能有效地一起工作；11）由于项目组成员间的冲突，导致沟通不畅、设计欠佳、接口错误和额外的重复工作；12）有问题的成员没有调离项目组，损害了项目组其他成员的积极性；13）项目的最佳人选未加入项目组；14）项目的最佳人选已加入项目组，但因其他原因未能合理使用；15

48、）没有找到项目急需的具有特定技能的人；16）关键人物只能兼职参与；17）项目人员不足；18）任务的分配与人员技能不匹配；19）人员工作的进展比预期的慢；20）项目管理人员怠工导致计划和进度失效；21）技术人员怠工导致工作遗漏或质量低下，工作需要重做。2.112.11 设计与实现设计与实现1）设计过于简单，无法确定主要事件，并导致重新设计和实现；2）设计过于复杂，导致一些不必要的工作，影响实现效率；3）设计质量低下，导致重复设计和实现4）使用不熟悉的方法，导致额外的培训时间，并重犯前期使用这种方法时导致的错误；5）产品采用低级语言来实施，导致生产率比预期的低；6）一些必要的功能无法使用现有的代码

49、和库实现，开发人员必须使用新库或自选开发所要的功能；7）代码和库质量低下，导致需要额外的测试、错误修正或重做；8）过高估计了增强型工具对计划进度的节省量；229）分别开发的模块无法有效集成，需要重新设计或重做。2.122.12 过程过程1）大量的纸面工作导致进程比预期的慢；2）进程跟踪不准确，导致无法预知项目是否已落后于计划进度；3）前期的质量保证行为不真实，导致后期的重复工作；4）质量跟踪不准确，导致无法得知影响进度的质量问题；5）太不正规，导致沟通不足，质量问题和工作重做；6）过于正规，导致过多耗时无用的工作；7）向管理层撰写进度报告占用的开发人员的时间比预期的多；8）风险管理粗心，导致没

50、有发现重大的项目风险；9）软件项目风险管理花费的时间比预期的多。23六六 开发进度月报开发进度月报l l标题标题开发中的软件系统的名称：机票预订系统（SMS）分项目负责人签名：黄珊本期月报编写人签名：陈君本期月报的编号：001本期月报报告的年月：2012-4-202 2工程进度与状态工程进度与状态2.12.1 进度进度本月内进行的各项主要活动：（1）问题识别：系统分析人员研究计划阶段产生的可行性研究报告和软件项目实施计划；（2）问题分析和方案的综合；（3）编制需求分析文档；（4）需求分析评审。重要事件：需求分析开始时间：2012-3-20截止时间：2012-4-272.22.2 状态状态本月的