移动体检车系统方案_第1页
移动体检车系统方案_第2页
移动体检车系统方案_第3页
移动体检车系统方案_第4页
移动体检车系统方案_第5页
已阅读5页,还剩110页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

体检车信息管理系统技术方案供应商:xxxxxx有限公司日期:.08.14 第一章标软公司介绍 原则体检信息管理系统的需求,重视软件的构造设计,在开发时完毕产品的文档,项目经理和项目构组员支持、理解质量控制组的工作,从系统设计开始,强调产品的质量,注产品的质量,严格按照质量规定完毕系统开发和设计工作,严格把握软件产品的变更过程,贯彻产品的审核和复审工作,从流程上和工作中控制产品质量,确保产品处在可控制的范畴内。

培训应用系统维护培训:培训对象为体检中心内容涉及系统总体构造、系统功效、数据库构造、系统的安装及运行管理、系统的维护。应用系统使用培训:培训对象为体检信息管理系统的应用系统的全部员工,分部门进行,重要内容是各自系统的重要功效和操作办法乙方承诺根据项目需要,制订应用软件培训计划,在征得甲方同意后,作为应用软件使用培训的根据。培训时间根据医院状况协调而定。培训地点由甲方定。培训细则详见我公司实施文档系列中的培训系列即“IMP.E.”系列文档如《项目培训计划书》等。

项目实施进度计划项目实施进度计划(项目开发部分时):阶段(普通每段为1/2周)实施试运行工作内容1st2nd3rd4th5th6th7st8nd1nd2nd…基础数据准备体检车系统安装,调试业务人员培训系统管理员培训基础数据维护培训考试内部测试运行试运行(每段为半周,并根据实际状况灵活调节,即,如果体检中心时间充足,人员到位,则为半周,即2.5天到3天为一种时间阶段,否则,可能会延长至4~5天为一种阶段)。

软件质量确保(SQA)计划引言目的本计划的目的在于对所开发系统软件规定多个必要的质量确保方法,以确保交付软件能够满足项目委托书或合同中规定的各项需求。

系统软件及所属的各个子系统(其中涉及为本项目研制或选用的多个支持软件)时,都应当报告本计划中的有关规定,但可根据各自的状况对计划作适宜的剪裁,以满足特定的质量确保规定,剪裁后的计划必须通过同意。定义本计划用到的某些术语的定义按GB/T11457和GB/T12505。参考资料GB/T11457软件工程术语GB8566计算机软件开发规范GB8567计算机软件产品开发文献编制指南GB/T12504计算机软件质量确保计划规范GB/T12505计算机软件配备管理计划规范管理机构在本软件系统整个开发期间,必须成立软件质量确保小组负责质量确保工作。软件质量确保小组属总体组领导,由总体组代表、项目的软件工程小组代表、项目的专职质量确保人员、项目的专职配备管理人员以及各个子系统软件质量确保人员等方面的人员构成,由项目的软件工程小组代表任组长。各子系统的软件质量确保人员在业务上受软件质量确保小组领导,在行政上受各子系统负责人领导。软件质量确保小组和软件质量确保人员必须检查和督促本计划的实施。各子系统的软件质量确保人员有权直接向软件质量确保小组报告子项目的软件质量状况。各子系统的软件质量确保人员应当根据对子项目的具体规定,制订必要的规程和规定,以确保完全恪守本计划规定的全部规定。任务软件质量确保工作涉及软件生存同期各阶段的活动,应当贯彻到日常的软件开发活动中,并且应当特别注意软件质量的早期评审工作。因此,对新开发的或正在开发的各子系统,要按照GB8566与本计划的各项规定进行各项评审工作。软件质量确保小组要派组员参加全部的评审与检查活动。评审与检查的目的是为了确保在软件开发工作的各个阶段和各个方面都认真采用各项方法来确保与提高软件的质量。在软件开发过程中,经总体组研究决定,在软件及其所属各子系统的开发过程中,应当进行下列三次内部评审:第一次评审软件需求、概要设计、验证与确认办法;第二次评审具体设计、功效测试与演示,并对第一次评审成果复核;第三次是功效检查、物理检查和综合检查。有关这些评审工作的具体内容见后边章节。阶段评审工作要组织专门的评审小组,原则上由项目总体小构组员或特邀专家担任评审组长,评审小构组员应当涉及项目委托单位或顾客的代表、质量确保人员、软件开发单位和上级主管部门的代表,其它参加人员视评审内容而定。每一次评审工作都应填写评审总结报告(RSR)、评审问题统计(RPL)、评审组员签字(RMT)与软件问题报告单(SPR)等四张表格。这四张阶段评审报表的具体格式应与附录C中的规定相一致。日常检查:在软件的开发过程中,各子系统应当填写项目进度报告。项目状态报告的格式与附录B中的规定相一致。软件验收:必须组织专门的验收小组对系统软件系统及其所属各个子系统进行验收。职责在软件质量确保小组中,其各方面人员的职责以下:组长全方面负责有关软件质量确保的各项工作;总体组代表负责有关阶段评审、项目进展报表检查以及软件验收准备等三方面工作中的质量确保工作。项目的专职配备管理人员负责有关软件配备变动、软件存储介质控制以及对供货单位的控制等三方面的质量确保活动;各子系统的软件质量确保人员负责测试复查和文档的规范化检查工作;顾客代表负责反映顾客的质量规定,并协助检查各类人员对软件质量确保计划的执行状况;项目的专职质量确保人员协助组长开展各项软件质量确保活动,负责审查所采用的质量确保工具、技术和办法,并负责汇总、维护和保存有关软件质量活动的各项统计。文档本章给出了在系统软件开发过程各阶段需要编制的文档名称及其规定,并且规定了评审文档质量的通用的度量准则。基本文档为了确保软件的实现满足需求,系统软件各开发单位最少应当编写下列八个方面内容的文档:软件需求规格阐明书;软件设计阐明书,对某些规模较大或复杂性较高的项目,应当把本文档分成概要设计阐明书与具体设计阐明书两个文档;软件测试计划;软件测试报告;顾客手册;项目实施计划;项目开发总结。其它文档除了基本文档之外,对于尚在开发中的软件,还应当涉及下列四个方面的文档:软件质量确保计划;软件配备计划;项目进展报表;阶段评审报表;注:前面两个文档由项目工程小组制订,属于管理文档,各个子系统的项目承接单位与软件开发单位都应认真执行计划中规定的条款。背面两类文档属于工作文档,就是本计划中提到的项目进展季报表。文档质量的度量准则文档是软件的重要构成部分,是软件生存周期各个不同阶段的产品描述。难作确认就是要检查各阶段文档的适宜性。评审文档质量的度量准则是有下列六条:完备性:应按照GB8567的规定编制对应的文档,以确保在开发阶段结束时其文档是齐全的。对的性:在软件开发各个阶段所编写的文档的内容,必须真实的反映阶段的工作且与该阶段的需求相一致。简要性:在软件开发各个阶段所编写的多个文档的语言体现应当清晰、精确简炼,适合多个文档的特定读者。可追踪性:在软件开发各个阶段所编写的多个文档应当含有良好的可追踪性。文档的可追踪性涉及纵向可追踪性和横向可追踪性两个方面。前者是指在不同的文档的有关内容之间互相检索的难易程序;后者是指拟定同一文档某一内容在本文档中的范畴的难易程度。自阐明性:在软件开发各个阶段所编写的多个文档应当含有较好的自阐明性。文档的自阐明性是指在软件开发各个阶段中的不同文档能独立体现该软件其对应阶段的阶段产品的能力。规范性:在软件开发各个阶段所编写的多个文档应当含有良好的规范性。文档的规范性是指文档的封面、大纲、术语的含义以及图示符号等符合有关规范的规定。原则、条例和商定在系统软件系统的开发过程中,还必须恪守下列原则、条例和商定:软件配备管理计划评审和检查本章具体规定了应当进行的阶段评审、阶段评审的内容和评审的时间规定。对新开发的或正在开发过程中的各个子系统,都要按照GB8566的规定进行定时的或阶段性的各项评审工作。就整个软件开发过程而言,最少要进行软件需求评审、概要设计评审、具体设计评审、软件验证和确认评审、功效检查、物理检查、综合检查以及管理评审等八个方面的评审和检查工作。如本计划前述,经总体研究决定,在系统及其所属各个子系统的开发过程中,把前七种评审分成三次进行。有每次评审之后,要对评审成果作出明确的管理决策。下面给出每次评审应当进行的工作。第一次评审第一次评审会要对软件需求、概要设计以及验证与确认办法进行评审。软件需求评审应确保在软件需求规格阐明书中规定的各项需求的合理性。概要设计评审应评价软件设计阐明书中的软件概要设计的技术适宜性。软件验证和确认评审应评价软件验证和确认计划中拟定的验证和确认办法的适宜性和完整性。第二次评审第二次评审会要对具体设计、功效测试与演示进行评审,并对第一次评审成果进行复核。如果在软件开发过程中发现需要修改第一次评审成果,则应按照软件配备管理计划的规定解决。具体设计评审应拟定软件设计阐明书中的具体设计在满足软件需求规格阐明书中的需求方面的可接受性。编程格式评审应确保全部编码采用规定的工作语言,能在规定的运行环境中运行,满足《语言编程格式商定》,并且符合GB8566中倡导的编程风格。在满足这些规定之后,方可进行测试工作评审。测试工作评审应对全部的程序单元进行静态分析,检查其程序构造(即模块和函数的调用关系和调用序列)和变量使用与否对的。在通过静态分析后,再进行构造测试和功效测试。要给出第个单元的输入和输出变量的变化范畴。各个子系统只进行功效测试,不单独进行构造测试,因而要登录程序单元之间接口的变量值。准则的那些测试用例在子系统功效测试时得到再现。测试测试工作评审要检查所进行的测试工作与否满足这些规定。特别在评审功效测试工作时,不仅要运行开发单位给出的测试用例,并且要允许运行任务委托单位或顾客、评审人员选定的采样用例。第三次评审第三次评审会要进行功效检查、物理检查和综合检查。这些评审会应在集成测试阶段结束后进行。功效检查应验证所开发的软件已满足在软件需求规格阐明书中规定的全部需求。物理检查应对软件进行物理检查,以验证程序和文档已经一致,并已做好了交付的准备。综合检查应验证代码和设计文档的一致性、接口规格阐明的一致性(硬件和软件)、设计实现和功效需求的一致性、功效需求和测试描述的一致性。软件配备管理对系统的各项配备进行及时、合同的管理,是确保软件的配备管理工作,可按软件工程小组编写的软件配备管理计划。在特别注意规定对软件问题报告、追踪和解决的环节,并指出实现报告、追踪和解决软件问题的机构及其职责。工具、技术和办法在项目所属的各个子系统(其中涉及有关的支持)的研制与开发过程中,都应当在各自的软件质量确保活动中合理地使用软件质量支持工具、技术和办法。这些工具重要有下列几个:软件配备管理工具。它支持顾客对源代码清单的更新管理以及对重新编译与连接的代码的自动组织;支持顾客有不同文档有关内容之间进行互相检索并拟定同一文档中的涉及范畴;同时还应支持软件配备管理小组对软件配备更改善行科学的管理。文档辅助生成工具与图形编辑工具。它重要协助顾客绘制描述程序流程与构造的DFD图与SC图、绘制描述软件功效(输入、输出关系)的曲线以及绘制描述系统特性的某些其它图形,同时还可生成若干与软件文档编制大概相适应的文档模板。顾客运用这个工具的正文与图形编辑功效以及上述辅助功效,能够比较方便地产生清晰悦目的文档,也有助于对文档进行更改,尚有助于提高文档的编制质量。存储介质控制为了保护计算机程序的物理介质,以免非法存取,意外损坏或自然老化,系统的各个子系统(涉及支持软件)都必须设立软件配备管理人员,并按照软件工程小组制订的、且经总体组同意的软件配备管理计划妥善管理和寄存各个子系统及其专用支持软件的介质。对供货单位的控制系统项目所属的各个子系统开发组,如果需要从软件销售单位购置、委托或其它开发单位开发、从开发单位现存软件库中选用或从项目委托单位或顾客的现有软件库中选用软部件时,则在选用前应向系统总体组报告,然后由系统总体组组织“软件选用评审、测试与检查,只有当演示成功、测试合格后才干同意选用。如果只选用其中部分内容,则按待开发软件的解决过程办理,此时系统总体组不予干预。统计收集、维护和保存在系统项目及其所属的各个子系统的研制与开发期间,要进行多个软件质量确保活动,精确统计、及时分析并妥善保存有关这些活动的统计,是确保软件质量的重要条件。在软件质量确保小组中,应有专人负责收集、汇总与保存有关软件质量确保活动的统计。要收集、汇总与保存的统计名字及其保存期限见后附录A。附录附录A:统计名称及其保存的期限表A:统计名称及其保存的期限统计的名称与分类要保存的期限阶段阶段评审总结整个软件开发周期评审阶段评审问题统计整个软件开发周期统计阶段评审重要问题整个软件开发周期阶段评审组员整个软件开发周期日常软件阶段进度整个软件开发周期检查软件阶段产品完毕状况整个软件开发周期统计软件开发费用统计表整个软件开发周期修改软件问题报告单整个软件开发周期统计软件问题修改单整个软件开发周期软件质量确保小组确保小构组员统计整个软件开发周期附录B:项目进展表项目进展报表(月报表或季报表)由一项目报表表头(表B1)和另一外三个表格(表B2、表B3、表B4)构成。在表B2中,要填写各个阶段的开工日期与结束日期。其中计划进度是指在项目实施计划中拟定的计划进度,因此能够管理人员事先填好,而不必由开发人员填写。实际进度是指该项目实际的开工日期与结束日期,它将随着该项目的不停进展来填写。其中进度是指项目组长发现实际进度与计划进度不符时提出的进度修改建议;但经项目管理人员研究后,可能对此修改建议作某些更改。另外,在相继的若干次报表中,项目组长提出的建议日期也可能是不相似的。在些我们规定,最后的调节进度由项目管理来拟定。在表B3“软件阶段产品完毕状况表”中,要填写各个文档的开始编写日期与完毕日期。其中有关对计划进度、调节进度与实际进度的含义的解释与上相似。表B4是有关统计软件开发费用的表格。表B1项目进展报表表头________年____月子系统名称模块名填表人填表日期_______年____月____日项目组长开发单位表B2软件阶段进度表子系统名:_____________________模块名:_____________________统计日期:_______年____月____日计划名称计划进度调节进度实际进度备注开工日期结束日期开工日期结束日期开式日期结束日期SA&SDRAPDDDCD&UTIT&STIS&ACTSSD注:SA&SD SystemAnalysis&SoftwareDefinitionphase系统分析与软件定义阶段RA RequirementsAnalysisphase需求分析阶段PD PreliminaryDesignphase概要设计阶段DD DetailedDesignphase具体设计阶段CD&UT CoDing&UnitTestingphase编码与单元测试阶段IT&ST InTegrating&SystemTestingphase组装与系统测试阶段IS&AC InStallation&ACceptancephase安装与验收阶段TSSD TotalSoftwareSystemDevelopmentphase整个软件系统的开发阶段表B3软件阶段产品完毕状况子系统名:_____________________模块名:_____________________统计日期:_______年____月____日文档名称计划进度调节进度实际进度页数备注开工日期结束日期开工日期结束日期开式日期结束日期1项目实施计划2需求规格阐明书3概要设计阐明书4具体设计阐明书5测试计划6测试报告7顾客手册8项目开发总结9源代码清单10质量确保计划11配备管理计划表B4软件开发费用统计表子系统名:_____________________模块名:_____________________统计区间:_______年____月____日至:_______年____月____日阶段名称人工费用(人月)其它费用(元)项目管理系统分析设计编码数据其它出差资料其它费用SA&SDRAPDDDCD&UTIT&STIS&ACTSSD附录C:项目阶段评审表C1在软件开发过程中的适宜阶段对软件阶段产品进行评审,是确保软件产品最后质量的重要办法。阶段评审能够对某个开发阶段产品进行评审,也能够对某几个开发阶段产品进行综合评审。在每次阶段评审中,必须推行正式手续,填写必要的评审表格,以利于项目管理工作,利于产品验收时的质量检查工作。项目阶段评审表由四张子表构成。表C1是对评审中发现的问题的统计RPL(reviewproblemlog);表C2是评审总结报告RSR(reviewsummaryreport);表C3是对其中重要问题的具体描述SPR(softwareproblemreport);表C4是评审小构组员登记与签字表。下面给出这四张表的格式。表C1评审问题统计(RPL)RPL评审问题记录登记号评审日期_____年___月___日评审性质评审复审项目名子项目名代号编号问题摘要问题类型与否解决123…表C2评审总结报告(RSR)RSR评审总结报告登记号评审日期_____年___月___日评审性质评审复审项目名子项目名代号阶段名软件定义需求分析概要设计具体测试编码测试组装测试安装验收运行维护项目组长姓名电话地址评审结论通过不需修改稍作修改不通过作重要修改要重新评审备注表C3软件问题报告单(STR)STR软件问题报告单登记号评审日期_____年___月___日发现日期_____年___月___日项目名子项目名代号阶段名软件定义需求分析概要设计具体测试编码测试组装测试安装验收运行维护状态1234567报告人姓名电话地址问题:例行程序程序数据库文档文档问题描述/影响:附注及修改建议:

表C4评审组员签字记录表(RMT)职务姓名职称单位签字评审小组成员组长1副组长2组员3456789项目实施过程文档《StandardPEIS项目实施过程文档》目录序号文档

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论