图书管理系统项目计划

图书管理系统工程方案目录1引言11.1背景11.2定义21.3参考资料21.4标准、条约和约定22工程概述32.1工程目标32.2产品目标与范围32.3假设与约束32.4工程工作范围32.5应交付成果42.5.1需完成的软件42.5.2需提交用户的文档42.5.3须提交内部的文档42.5.4应当提供的效劳52.6工程开发环境53工程团队组织53.1组织结构53.2人员分工63.3协作与沟通83.3.1工程团队内部协作83.3.2工程接口人员83.3.3工程团队外部沟通与协作模式84实施方案84.1风险评估及对策84.2工作流程124.3总体进度方案134.4工程控制方案144.4.1质量保证方案144.4.2进度控制方案154.4.3预算监控方案154.4.4配置管理方案165支持条件175.1内部支持175.2客户支持175.3外包〔可选〕176预算176.1人员本钱176.2设备本钱186.3其它经费预算187关键问题188专题方案要点19图书管理系统工程方案1引言1.1背景工程的名称图书管理系统工程建设背景随着人们知识水平层次的提高，图书馆成为日常生活中不可缺少的一局部。而图书馆的存书量和业务量庞大，仅仅靠传统的记帐式管理是不可行的。图书馆系统应运而生，逐渐成为信息化建设的重要组成局部。图书馆管理系统为学校或社会型图书馆的管理员提供所有借阅者的详细信息，以及馆内库存的详细情况，对借书和还书两大功能进行合理操纵并登记。软件系统与其他系统的关系本系统属于整个公司开展的系统建设的根底性系统，主要是尝试性的为客户提供效劳的同时，逐步建立并完善一个独立的数据库，大范围的集结优秀的工程管理工程案例。未来在这个根底的骨干系统的根底上逐步完善各个子系统，并开展成为功能完善、功能强大的独立系统。优秀的工程管理案例可以挂在工程管理职能部门的相关网页下供社会学习参考。软件系统与机构的关系该系统出了为本公司的客户提供相关的效劳之外，还应该在工程管理职能部门下设立有关优秀的工程管理案例供社会学习参考。1.2定义Sql语言：是指根本通用的数据库操作语言。GUI编程：是指图形界面编程。1.3参考资料文档格式要求按照我国GB/T8567-1988国家标准和IEEE/ANSI830-1993标准标准要求进行。包括以下文件：a.图书借阅关系系统需求说明书b.软件工程工程开发文档范例c.软件工程国家标准文档d.图书借阅管理需求说明书e.软件需求说明书编写标准书籍包括：《软件工程管理》夏辉，周传生，清华大学出版社。1.4标准、条约和约定本工程遵从以下标准：GB/T13702-1992计算机软件分类与代码GB/T20918-2007信息技术GB/T19003-2023软件工程GB/T5538-1995软件工程标准分类法GB/T9386-2023计算机富安居测试文档编制GB/T9385-2023计算机软件需求规格说明GB/T5532-2023计算机软件测试标准GB/T18221-2000信息技术程序设计语言GB/T11457-2006信息技术软件工程GB/T8567-2006计算机软件文档编制标准2工程概述2.1工程目标本工程的总目标是完成图书馆管理系统，为实现此目标，必须实现一下三个阶段目标：第一阶段目标：总体设计出图书馆管理系统总框架，并分析所需功能。第二阶段目标：大体完成图书馆管理系统。第三阶段目标：对完成的管理系统测试并验收。2.2产品目标与范围本工程产品的目标是实现图书馆对图书的智能化、信息化、简单化，通过该系统来代替以往复杂软件操作存在的弊端。系统的主要功能是实现图书信息的增加、删除、修改、查找、借阅、还书的显示操作，及实时数据库提交更改。提高图书管理员工作信息报送反应工作效率，更好的统计信息，提高信息的及时性、汇总统计信息的准确性，减轻管理员的劳动强度。2.3假设与约束本工程的开发时间为:工作人员：6人开发经费预算：90万设备：7台PC假设：1、本公司的资金充足，所有硬件设施如假设需要就能在三天内投入使用，并且已经办完了所有的系统开发相关手续。2、人员充足且协作能力强，工作效率高，能够迅速的通过努力完成所交付的任务。3、严格跟进，不能超过方案的时间。约束：1、系统开发，原那么上严格控制本钱，不能超过预算的10%。2、必须在工程经理的有效指挥下严格完成任务，投入的人员不能超过5人。3、人力资源的约束限制，就必须牺牲进度或质量。2.4工程工作范围为了使本系统成功到达客户的要求，需完成如下任务：系统需求分析、系统概要设计、编码设计、以及系统测试和维护。2.5应交付成果2.5.1需完成的软件程序名称：图书馆管理系统编程语言：C#+SQLServer2005软件对象：源程序、可执行程序、支撑系统的数据库数据、安装软件。2.5.2需提交用户的文档安装维护手册：主要内容是介绍安装和维护的主要步骤和考前须知。使用手册：主要内容是向用户介绍如何使用该系统。需求规格说明书：向用户介绍该系统的需求规格说明。2.5.3须提交内部的文档1．软件工程管理方案该文档由组长完成，介绍工程的整个管理过程。该文档在软件设计需求分析初级阶段完成，后续阶段由文档维护员进行相应的更新。2.需求规格说明初稿在需求分析阶段，由全体小组成员采集分析用户的需求，并在例会上作出决策，有文档维护员撰写整理需求规格说明初稿，并在后续各个阶段进行需求变更的更新。3.设计报告初稿在总体设计阶段，小组根据需求规格说明文档，完成软件体系结构的设计，由组长编写软件体系结构设计文档初稿，并在后续开发阶段补充和更新。该文档由文档维护员负责维护更新。4.测试文档在软件开发阶段，测试人员需要编写测试规格说明文档，并在后续测试阶段更新。开发人员将根据测试规格说明文档建立测试环境、准备测试数据。5．用户手册在更新用需求分析阶段，测试人员需要开始着手编写用户手册，并在需求分析结束后需要形成初稿；在后续阶段不断由文档维护员户文档；并在系统交付阶段随着系统一起被交付。6.个人工程总结由组内成员各自独立完成，对开发过程中获得的工作经验进行总结。在提交系统时一并提交。7.其他文档软件开发过程中的其他文档，如开发日志〔按组员意见选择公开与否〕，风险报告及其处理意见等，由秘书进行整理与会聚。作为以后软件开发以及交流的经验。2.5.4应当提供的效劳将向用户演示安装、维护以及运行使用。2.6工程开发环境1、软件：Eclipse\visualstudio\Dreamweaver\Firework2、硬件：PC机3、技术：ASP＼HTML＼CSS＼VBscript\javascript\SQL4、工程设计及运行平台WindowsXPwebIIS2.7工程验收方式与依据代码的验收：在交付客户之前进行小组内评审，代码编写符合HB6465标准，与文档说明保持一致，代码书写风格统一，采用标准标准，没有以下错误：由于软件缺陷造成丧失数据，不符合设计要求，响应时间太长无法接受等问题。文档验收：在交付客户之前进行小组内评审，文档格式符合HB6465标准，功能符合与客户的合同要求，清晰易读，没有语病与歧义。效劳验收：效劳硬件到达文档说明的要求，人员技术考核合格，定期上门维护。3工程团队组织3.1组织结构设计经理设计经理测试经理开发经理工程经理需求分析组界面设计组文档编写组概要设计组框架设计组详细设计组测试组测试用例设计组测试脚本开发组3.2人员分工姓名角色工作描述×××工程经理01.工程沟通交流02.工程进度掌控03.核心技术框架制定04.工作任务划分分配、审核、验收05.开发平台建设06.样例程序制作07.日常管理工作08.重要文档成果物的整理09.测试验收各个模块10.架构设计整个系统的核心权限局部11.解决疑难技术问题12.模块设计指导×××开发经理开发工程进度掌控工作任务划分分配、审核、验收测试验收各个模块日常管理工作×××××××××开发人员分析系统需求分析界面设计文档编写×××设计经理分析新功能软件框架扩展代码模块分配数据库设计说明书×××设计人员01.数据交换02.安装程序03.安装手册×××设计人员01.数据加载分析×××设计人员工程后期总体负责加载程序编写×××设计人员01.数码相机照片读取剪切模块设计×××测试人员对软件进行测试编写软件测试文档×××测试人员01.用户操作手册3.3协作与沟通3.3.1工程团队内部协作本工程由工程经理领头协调各个工程组成员的协调工作。下设小组长×××、×××。主要通过企业内部邮箱联系，工程团队的每一个成员都有一份工程成员联系方式单。在每一工程阶段的开始和结束时都由工程经理组织召开工作大会。并由×××做好会议记要，并归档统一管理。3.3.2工程接口人员(1)负责本工程同用户的接口人员本工程有公司自主开发，供公司开展使用。主要是由工程经理同开发设计部街头。(2)负责本工程同本企业开发设计部接口人员仍旧由工程经理担任接口人员。工程经理与开发设计部和公司的职能部门的交接内容由专人负责记录，并交由×××统一归档。3.3.3工程团队外部沟通与协作模式工程团队外部由工程经理负责沟通协作。在每一工程阶段的开始和结束时，工程经理结束团队内部工作安排总结之后，需要向公司相关职能部门提交报告，报告交由×××统一归档保管。联系方式：开发设计部：：151****0326〔部长助理〕邮箱：××××××@qq紧急联系方式〔仅供特殊情况下使用〕：：158****9469〔李经理〕邮箱：××××××@qq4实施方案4.1风险评估及对策风险识别风险定性与定量分析风险应对编号WBS模块风险事件风险概率风险影响描述风险影响值风险期望值排序级别缓解策略策略应急方案和巢湖发事件风险处理措施风险负责人1需求风险需求分析不到位，导致数据模型建立好后无法使用6%10%≤本钱增长<20%0.20.128四级1、重新进行到位的需求分析1当数据模型建立后无法使用时，即使重新做需求分析一周工作包负责人2需求风险缺少有效的需求变化管理过程10%5%≤进度实施<10%0.20.0206四级1、及时和工程经理进行有效的沟通，确保需求的有效管理1、当缺少有效的需求变化管理过程时，要及时，与相应的管理人员惊醒沟通，制定有效的变化管理三天工作包负责任3需求风险客户不断变化需求9%工作质量受到较小的影响0.10.0099四级1、要做好与客户之间的沟通工作2、工作人员要做好应对必要变化的准备，满足客户的需求当客户不断变化需求时，1、要做好与客户之间的沟通工作2、工作人员要做好应对必要变化的准备，满足客户的需求一周工作包负责人4需求风险院图书馆调研经常推后20%10≤进度拖延<0.40.0801三级与客户相关人员惊醒有效沟通当需求调研不能及时进行时，根据合理时间调研并与相关工作人员进行有效沟通并确定调研时间两天工程经理5需求风险某些需求超出工程范围25%范围主要局部受到影响0.20.0503三级查看范围进度方案，并与客户，进行合理的沟通1、某些需求超出工程范围时，1、明确列出超出工程范围需求，2查看范围进度方案，并与客户，进行合理的沟通一天工程经理6需求风险漏掉某些模块或多了某些模块6%范围的次要不分受到影响0.10.00611四级查看范围进度方案，及时修改当漏掉某些模块或多了某些模块时，1、查看范围进度方案，及时与工程经理进行沟通，如果漏掉某些模块，及时把漏掉的任务分配给相应的工作人员进行补充，如果多了一些设计模块，查看进度，并决定是否删除多出的模块一周工作包负责人7相关性风险签订合同不科学不严谨，存在边界界定不清楚的问题15%10%≤进度实施<20%0.40.06010四级及时与客户进行有效沟通并重新修订合同当合同有问题时，1、及时与客户进行有效沟通，并进行重新修订合同，2、重新根据需求制定更加完美的合同桑拿天工程经理9相关性风险软硬件不兼容1%工程的最终产品实际上不能使用0.80.04012四级及时与供给商联系，并进行有效沟通，更换硬件设备当软硬件不兼容时1、及时与供给商联系，并进行有效沟通，更换硬件设备2、如果无法更换，查看该硬件是否可以用在该系统的其他位置三天工作包负责人10相关性风险病毒、黑客入侵造成系统无法正常工作5%工程的最终产品实际上不能使用0.60.05016三级做好系统平安防护当病毒、黑客入侵造成系统无法正常工作时，1、及时进行系统体检，用相关工具杀毒，2、通过相关设备对系统进行有效保护防止系统再次收到攻击11技术风险预算有误，导致开发过程无法进行9%10%≤进度实施<20%0.20.0187四级向投资者申请新的的资金当预算有误，导致开发过程无法进行时，向投资者申请新的的资金，2、向投资者展示新的预算和以前错误的预算一周工作包负责人12技术风险开发工具不可靠导致工程过程中的bug5%10%≤进度实施<20%0.40.0.0325四级确定开发工具可靠当开发工具不可靠时，1、及时做测试，发现bug。2、更换开发工具一周工作包负责人13技术风险使用框架存在漏洞bug，导致工程失败1%质量降低需要得到有关领导的批准0.20.00213四级测试人员及时发现问题，开发人员及时解决问题当使用框架存在漏洞bug，导致工程失败时，1、及时对框架进行修复2、更换更可靠的框架一周工作包负责人14管理风险技术人员离职，模块任务无人完成5%10%≤进度实施<20%0.30.0502三级1、加强人员考核；确定人员的可靠性2、及时需找人员代替气工作当技术人员离职，模块任务无人完成时1、加强人员考核；确定人员的可靠性2、及时需找人员代替气工作3、与当事人做及时沟通，2天工程经理15管理风险不能按进度方案完成相应的任务2%10%≤进度实施<20%0.30.06014四级做好跟踪记录当不能按进度方案完成相应的任务时，1、做好对每个人的及时跟踪记录，2、假设不能按进度完成，应当进行加班完成相应任务一周工作包负责人15管理风险进度进化不够完善导致整体任务滞后5%质量降低需要得到有关领导的批准0.60.08615三级及时调整方案当进度进化不够完善导致整体任务滞后时1、及时调整方案2、将所差进度加班完成2天工作包负责人16自然风险火灾、涝灾、地震等自然灾害1%质量降低需要得到有关领导的批准0.30.02016三级做好转移工作，降低损失程度当火灾、涝灾、地震等自然灾害时1、做好系统备份的转移工作，把损失降低到最小2及时做出应急处理，是相关负责人做出快速反映。三天工作包负责人4.2工作流程工程方案工程方案需求分析概要设计数据库设计编码实施系统测试结项SQA配置管理4.3总体进度方案起止时间责任人及所需资源完成工作应提交成果检查点/里程碑工程经理以及各部门负责人工程立项立项报告高层经理审批工程团队建立SM和PM决定，SQA人员由中心确定工程生命周期模型选择工程方案中的生命周期需求开发过程定义需求开发方案简单制定需求开发方案软件评估和风险评估软件评估开发书、软件开发方案、风险管理方案和日志简单执行培训方案制定培训方案软件开发方案文档化软件开发方案测试方案测试方案工程结项工程总结报告、验收报告概要编写需求分析人员客户需求调研、需求分析、软件需求走查、需求组内正式评审软件需求规格说明书、评审准备表、报告设计人员界面设计、总框架设计界面设计报告、框架设计报告表编程人员系统编程编程源代码系统可运行测试人员测试软件测试阶段报告、系统测试评估、操作手册、用户手册、测试阶段度量数据工程经理以及各工程负责人验收、维护验收报告、工程总结报告工程经理用户验收4.4工程控制方案4.4.1质量保证方案执行时间阶段任务人员分工×月×日×月×日×月×日×月×日×月×日需求分析需求评审开发经理系统与测试设计系统概要设计评审系统详细设计评审制定测试策略评审制定测试方案评审编码与测试执行制定编码标准评审设计经理测试需求评审测试经理代码审查单元测试报告评审测试用例评审缺陷报告评审测试评估与系统部署测试评估报告评审部署方案评审工程经理4.4.2进度控制方案时间阶段任务人员分工201×年×月201×年×月201×年×月工程启动与方案工程经理技术专家需求分析开发经理系统与测试设计系统概要设计设计经理系统详细设计制定测试策略测试组长制定测试方案编码与测试执行制定编码标准设计经理确定测试需求测试经理编码设计经理单元测试编写测试用例测试经理执行测试测试评估与系统部署测试评估制定部署方案开发组长4.4.3预算监控方案活动小活动预算小活动分摊预算大活动分摊预算累计工程规划1、模板确定1320396013202、撰写工程方案报告26403960需求分析3、需求调研26401188066004、需求分析5280118805、需求确认2640145206、撰写需求分析说明书132015840软件设计7、系统分析396025080198008、模块设计9240290409、数据库设计66003564010、美工设计39603960011、撰写详细设计说明书132040920软件开发12、硬件安装25900457006682013、环境配代码实现1848086620软件测试15、集成测试5280118809190016、系统测试52809718017、撰写系统测试报告132098500验收总结18、撰写用户手册132052809982019、人员培训132010114020、产品转移132010246021、经验总4.4配置管理方案采用专用的版本管理工具进行软件版本的控制，如SVN或是Git之类的管理工具。〔1〕人员与职责版本控制管理者：工程经理职责：制定版本控制流程〔2〕确定版本库的用户权限管理者：负责版本管理、对版本库拥有全部权限开发人员：写入读出测试人员：读〔3〕定义配置项〔版本控制项〕及其标识系统工程方案系统需求说明系统概要设计系统详细设计测试策略测试方案测试用例编码标准源代码缺陷报告测试最终结果报告〔4〕定义工程基线〔略〕〔5〕定义配置项的版本管理策略按照4类不同功能的分支进行：主干分支私有分支小组分支集成分支5支持条件5.1内部支持无5.2客户支持需求分析阶段：客户201×年×月×日参与到此阶段，需求分析人员记录需求。客户验收阶段：客户于×月×日对本系统验收。5.3外包〔可选〕无6预算6.1人员本钱姓名标准费率加班费×××￥330/工作日￥50/小时×××￥250/工作日￥40/小时×××××××××￥200/工作日￥35/小时×××￥250/工作日￥40/小时×××￥200/工作日￥35/小时×××￥200/工作日￥35/小时×××￥200/工作日￥35/小时×××￥200/工作日￥35/小时×××￥200/工作日￥35/小时×××￥200/工作日￥35/小时6.2设备本钱所有设备均有，本钱为0。6.3其它经费预算1差旅费3500交通费用、伙食费、住宿费以及差