软件开发管理制度39139

-.z软件开发管理制度第一节总则第一条为规*自有软件研发以及外包软件的管理工作,特制定本制度。本制度适用于公司软件研发与管理。第二条本制度中软件开发指新系统开发和现有系统重大改造,此类工作均需要以工程制管理。第三条本制度中自行开发是指主要依赖公司自身的管理、业务和技术力量进展系统设计、软件开发、集成和相关的技术支持工作,一般仅向外购置有关的硬件设备和支撑软件平台;合作开发是公司与专业IT公司(合作商)共同协作完成IT应用的工程实施和技术支持工作,一般形式是公司负责提供业务框架,合作商提供技术框架,双方组成开发团队进展工程实施,IT系统的日常支持由技术研发部承担;外包开发是指将IT应用工程的设计、开发、集成、培训等任务承包给*家专业公司(可以是专业的IT公司或咨询公司等),由该公司(承包商)负责应用工程的实施。第四条软件开发遵循工程管理和软件工程的根本原则。工程管理涉及立项管理、工程方案和监控、配置管理、合作开发管理和结项管理。软件工程涉及需求管理、系统设计、系统实现、系统测试、用户承受测试、试运行、系统验收、系统上线和数据迁移。第五条除特别指定,本制度中工程组包括业务组(或需求提出组)、开发组(可能包括网络管理员和合作开发商)。第二节立项管理第六条提出工程需求的部门参与公司层面立项,进展立项的技术可行性分析,编写?立项分析报告?(一),开展前期筹备工作。?立项分析报告?应明确工程的*围和边界。第七条需求提出部门将?立项分析报告?交相关部门会签后,上交公司总裁与董事长进展立项审批,以保证系统工程与公司整体策略相一致。第八条?立项分析报告?得到批准后,成立工程组(如果是外包开发,则成立外包商工程组;如果是合作开发,则与外包商共同成立合作开发工程组,以下统称“工程组〞),工程组应包括业务组(由公司技术研发部需求管理组和相关业务部门组成)和开发组(自行开发为技术研发部开发组、网络管理员;外包开发为技术研发部指定的开发组长、网络管理员和外包商成员;合作开发为技术研发部开发组指定人员、网络管理员和外包商成员)。公司技术研发部PMO(工程管理办公室)委派一名工程经理负责监视工程的进度,进展工程管理工作,确保开发能及时完成并能满足业务需要。工程组人员的选择应满足工程对业务及技术要求,工程组人员应有足够的业务和IT技术方面的专业知识来胜任工程各方面的工作。第三节需求分析第九条立项后业务组对用户需求进展汇总整理,出具?业务需求说明书?(二),并确保?业务需求说明书?中包含了所有的业务需求。经系统使用部门审批确认,作为业务需求基线。第十条业务组在获得?业务需求说明书?后,提出技术需求和解决方案,并对系统进展定义,出具?系统需求规格说明书?(三)。?系统需求规格说明书?需详细列出业务对系统的要求(界面、输入、输出、管理功能、平安需求、运作模式、关键指标(KPI)等),最好是采用原型方式表达。?系统需求规格说明书?需要由业务组提交给相关业务部门负责人确认。第十一条对于合作开发的工程,当业务需求发生变更时,业务组应提交?需求变更申请?(四),工程经理审批后交给开发组长实施。第十二条工程组应对需求变更影响到的文档及时更新。第四节工程方案和监控第十三条软件开发采用工程形式进展管理。工程经理负责整个工程的方案、组织、领导和控制。第十四条需求分析过程中,工程经理组织制定详细的?工程方案书?(五),包括具体任务描述和工程进度表等。第十五条在工程的各个阶段,业务组组长和开发组组长需配合工程经理制定阶段性工程方案。业务组组长和开发组组长需配合工程经理对工程方案执行情况进展监控,确保工程按方案完成。第十六条工程方案需要变更时,工程经理填写?工程方案变更说明?(六),并提交公司主管领导审批,通过审批后,交给业务组组长和开发组组长执行。第五节系统设计第十七条系统设计应分为概要设计和详细设计,系统设计要遵循完备性、一致性、扩展性、可靠性、平安性、可维护性等原则。第十八条在系统设计阶段中,用户应充分参与,确保系统设计能满足系统需求。第十九条工程组进展设计,出具?设计说明书?(七)和?单元测试用例?(八)。?设计说明书?中需要定义系统输入输出说明和接口设计说明。公司主管领导组织相关人员对概要设计进展评审,出具?设计评审报告?(九)。业务组组长和开发组组长应参加此评审并对评审意见签字确认。第二十条设计评审均以?业务需求说明书?和?系统需求规格说明书?为依据,确保系统设计满足全部需求。第二十一条对已确认通过的系统设计进展修改需获得工程经理、业务组组长和开发组组长的审批前方可进展。第二十二条对系统设计的修改的文档须由文档管理人员进展归档管理。第六节系统实现第二十三条开发组根据?设计说明书?制定系统实现方案,并提交工程经理对方案可行性进展审批。第二十四条系统实现包括程序编码、单元测试。第二十五条开发组保证开发、测试和生产环境独立,为各环境建立访问权限控制机制,并明确工程成员的职责分工。对开发环境、测试环境与生产环境在物理或逻辑方面应该做到隔离;如果环境的分隔是通过逻辑形式实现的,应定期检查网络设置。工程组对已授权访问生产环境的人员进展详细记录,并对该记录进展定期检查,确保只有经授权的人员才能访问到生产环境。第七节系统测试和用户测试第二十六条测试组制定?系统测试方案?(十),并提交工程经理对方案可行性进展审批。第二十七条?系统测试方案?必须定义测试标准,并明确各种测试的测试步骤和需要的系统设置要求。第二十八条开发组向数据拥有部门申请获取测试用业务数据的使用权,对获取的数据进展严格的访问控制,确保只有相关工程人员才能访问及使用。第二十九条开发组负责测试数据准备,测试用数据要足够模拟生产环境中的实际数据。对已评定为敏感信息的数据进展敏感性处理和保护。第三十条开发组或合作开发商协助技术研发部测试组建立测试环境进展系统测试。在系统测试中对新系统内部各模块之间的接口和与其他系统的接口进展充分测试。技术研发部测试组出具?系统测试报告?(十一),测试人员签字确认测试结果。第三十一条系统测试通过后,开发组配合业务组建立用户测试环境,业务组根据用户测试用例进展用户测试,出具?用户测试报告?(十一),业务组组长和开发组组长应在用户测试报告中签字确认。第三十二条工程组完成系统帮助文档(其中包括?用户操作手册?和?安装维护手册?)。凡涉及应用系统的变更,应对系统帮助文档及时更新。第八节试运行第三十三条系统主要使用部门根据工程规模及影响决定试运行策略。第三十四条工程组制定?试运行方案?(十二),并制定试运行验收指标,上报公司主管领导审批。?试运行方案?中应包含问题应对机制,明确问题沟通渠道和职责分工。第三十五条工程组联合试运行单位进展相关系统部署工作,准备培训资料,对相关用户和信息技术人员进展培训。用户培训的完成度应为实施后评估的指标之一。第三十六条工程组根据?试运行方案?进展系统转换和数据迁移。系统转换前,检查系统环境,确保运行环境能满足新应用系统的需要。系统转换时必须详细记录原系统中的重要参数、设置等系统信息,并填写试运行报告相关内容。系统参数、设置的转换工作作为系统上线的验收的评估指标之一。第三十七条数据迁移前,应制定详细的?数据迁移方案?(十三),?数据迁移方案?中应包含迁移方案、测试方案、数据定义,新旧数据对照表、迁移时间、回退方案等信息。数据迁移方案需经工程经理和主管领导签字审批。第三十八条数据迁移后,工程组对数据迁移的完整性和准确性作出检查,出具?数据迁移报告?(十四),其中包括数据来源、转换前状态、转换后状态,数据迁移负责人、对完整性检查情况、对准确性检查情况等内容。各相关部门验收转换结果后在该报告上签字确认。第三十九条系统转换和数据迁移由试运行单位业务部门和公司主管领导共同监视并进展验收。第四十条系统转换和数据迁移验收通过后,正式启动试运行。在试运行过程中,试运行单位办公室把系统运行情况(系统资源使用,反响速度等)记录到试运行报告中。必要时,工程组应根据系统运行情况对应用系统进展优化。第四十一条试运行到达试运行方案规定的终止条件时,工程组编写?试运行报告?(十五)。此报告应由工程组和试运行单位签字确认,并提交公司主管领导审阅。公司主管领导审阅试运行结果,决定试运行完毕或延期。第九节系统验收第四十二条系统主要使用部门及技术研发部联合组成独立系统验收小组,也可授权原工程组作为验收小组。验收小组从功能需求及技术需求层面对系统进展综合评估。第四十三条验收小组应根据验收情况整理形成?系统验收报告?(十六)提交系统主要使用部门和技术研发部审阅。第四十四条系统主要使用部门和信息技术部门负责人根据系统测试、试运行情况签署验收意见。第十节系统上线第四十五条系统上线应遵循稳妥、可控、平安的原则。第四十六条通常情况下,系统上线包含数据迁移工作。第四十七条工程组制定?系统上线方案?(十七),上报公司主管领导审批。在上线方案得到批准后才能开场部署上线工作。第四十八条?系统上线方案?内容应包括但不限于:1、部署方式和资源分配(包括人力资源及效劳器资源);2、上线工作时间表;3、上线操作步骤以及问题处理步骤;4、工程阶段性里程碑和成果汇报(工程执行状态的审阅、进度安排等);5、数据迁移的需求和实施方案;6、完整可行的应急预案和“回退〞方案;7、用户培训方案(包括:培训方案、培训手册、培训考核等);8、公司下发的系统标准参数配置。第四十九条上线单位在上线初期需加强日常运行状态监控,出现问题时应及时处理,对重大问题应启动紧急预案。第五十条在完成上线后要填写?系统验收评估报告?(十八)。?系统验收评估报告?内容包括:数据准确性、系统性能及稳定性、接口问题、权限问题、业务操作影响度、问题处理情况、备份、批处理等。第五十一条上线单位管理层要对?系统验收评估报告?进展审批签字。第五十二条公司主管领导批准结项后,业务组和开发组将整理的文档提交各自部门统一管理。第十一节合作开发管理第五十三条第五十四条第五十五条第五十六条第五十七条第五十八条第五十九条第六十条第六十一条第六十二条6、完整可行的应急预案和“回退〞方案;7、用户培训方案(包括:培训方案、培训手册、培训考核等);8、公司下发的系统标准参数配置。上线单位在上线初期需加强日常运行状态监控,出现问题时应及时处理,对重大问题应启动紧急预案。在完成上线后要填写?系统验收评估报告?(十八)。?系统验收评估报告?内容包括:数据准确性、系统性能及稳定性、接口问题、权限问题、业务操作影响度、问题处理情况、备份、批处理等。上线单位管理层要对?系统验收评估报告?进展审批签字。公司主管领导批准结项后,业务组和开发组将整理的文档提交各自部门统一管理。合作开发商的选择应遵循公司相关规定,合作商资质认定参见第三方管理制度。合作开发商必须遵循公司?软件开发管理制度?。工程经理同合作开发商明确规定工程变更的*围和处理方式,重点关注需求和设计变更。工程经理负责监控合作开发商的工程管理及软件开发活动。合作开发商应按方案定期向工程经理报告进展状态,并提交阶段性成果文档。发生重大问题时,合作开发商需及时向工程经理汇报。开发组组长派专人监控合作开发商的质量保证过程。工程组同合作开发商商定验收的标准和方法。以上各要求需要在开发合同中明确。第十二节系统交付在系统验收通过后,工程组对运维组进展系统维护培训。工程组提交全部经审批的交付物给PMO存档。工程组填写?系统交付申请?(十九),提交主管技术总裁审批后,交付运维组。第7页,共53页技术开发管理制度第六十三条第六十四条第六十五条第六十六条第六十七条第六十八条第六十九条第十三节外包开发管理立项申请得到公司主管领导的审批后,选定开发商,签订外包开发合同。工程经理负责监控外包开发商的工程管理及软件开发活动。外包开发商应按方案定期向工程经理报告进展状态,并提交阶段性成果文档。发生重大问题时,外包开发商需及时向工程经理汇报。工程经理监控外包开发商的质量保证过程。工程组同外包开发商商定验收的标准和方法。以上各要求需要在开发合同中明确。第十四节附则本制度由公司技术研发部负责解释和修订。本制度自发布之日起开场执行。第8页,共53页技术开发管理制度一立项分析报告版本历史1.工程介绍1.1.

工程目的提示:用简练的语言说明本工程“是什么〞,“实现什么目的〞。描述简练且清晰。1.2.

工程背景提示:阐述工程背景,重点说明“为什么〞会产生本工程。(1)公司的短期、长期开展战略;(2)业务需求及开展趋势;(3)技术状况及开展趋势;(4)特殊的业务需求等。1.3.

工程*围提示:根据对现有需求的了解来确定工程根本*围,说明本系统“应当包含的内容〞和“不包含的内容〞。2.工程方案2.1.工程团队提示:说明工程团队的角色、知识技能要求、建议人选、人数、工作时间,如下表所示。文件状态:[√]草稿[]正式发布[]正在修改文件标识:ProjectName-当前版本:*.Y作者:完成日期:Year-Month-Day版本/状态作者参与者起止日期备注角色知识技能要求建议人选、人数工作时间工程经理需求开发人员系统设计人员第9页,共53页技术开发管理制度编程人员测试人员质量保证人员配置管理人员效劳与维护人员......2.2.本钱估计内容本钱(人民币)备注人力资源软硬件资源差旅费会议费接待费...2.3.进度表提示:制定工程开发的进度表(建议给出工程里程碑方案)。例如:编号里程碑名称预计完毕时间备注需求调研完成工程方案完成需求分析完成概要设计完成详细设计完成实现完成集成测试完成系统测试完成用户验收测试完成试运行完毕工程验收3.总结提示:给出清晰的建议结论,便于上级领导决策。第10页,共53页技术开发管理制度二业务需求说明书版本历史1概述1.1业务调研人员【可选】1.2业务*围此处描写总体业务的概要分类并。1.3业务目标从高层或商务利益的角度提出本业务系统的期望目标,以及评价标准。1.4相关文档说明:列出本文档的所有参考文献(可以是非正式出版物),包括现有规*、标准、批文、引用到的文件、资料等。1.5业务词汇表说明:列出本文档的所引用的专属领域词汇、术语等,以便于业务需求的提供者和接收者是建立在一致的业务理解根底之上的。2组织构造及业务2.1业务相关组织构造、人员组织构造说明:如果客户岗位设置复杂可分别设置,业务组织构造和人员组织构造文件状态:[√]草稿[]正式发布[]正在修改文件标识:ProjectName-当前版本:*.Y作者:完成日期:Year-Month-Day版本/状态作者参与者起止日期备注序号职能部门**主管联系备注第11页,共53页技术开发管理制度2.2组织机构描述2.3角色职责说明:将业务涉及的具体人员进展一定程度的分类和抽象,描述该抽象角色的操作职责。2.4管理综述【可选】说明:主要描述该业务的管理特点和管理模式。例如:典型按库存生产模式。生产方案以年度销售方案为指导,并综合考虑设备能力、生产天数、库存、历史销售记录。采购方案的制订以生产方案为依据。2.5现有业务流程清单【可选】说明:现有业务流程需要考虑,很多新的业务是在已有业务流程根底上进展重组的。3业务流程及业务处理描述说明:针对每一项具体的目标业务,描述具体的业务流程,以及相关业务的具体描述。3.1具体业务流程(系统名称+编号)对于具体业务流程的命名有规*,对具体流程进展编号,便于形成需求矩阵,同时形成需求的管理和跟踪。3.1.1业务流程3.1.2业务描述说明:描述具体的业务流程。3.1.3相关业务对象说明:业务对象:业务流程中涉及的单据、报表等。3.1.4业务规则及关键算法说明:描述业务环节关键算法体系。4假定和约束说明:列出进展本软件开发工作的假定和约束,例如开发期限等。4.1运行环境约束流程编号流程名称责任部门辅助部门业务对象使用部门对应电子档案编号第12页,共53页技术开发管理制度4.2设计约束【可选】说明:开发过程中必须使用的软件语言、软件进程需求、主要开发工具、核心技术、第三方产品等。4.3产品应当遵循的标准或规*【可选】说明:阐述本产品应当遵循什么标准、规*或业务规则,违反标准、规*或业务规则的产品通常不太可能被承受。5其他5.1目前核心问题和困难5.2业务对工程实施的需求和期望【可选】5.3其他未尽事宜第13页,共53页技术开发管理制度三系统需求规格说明书版本历史1引言1.1目的例如:规定系统的边界和目标,描述系统的功能性需求和非功能性需求。1.2读者对象及阅读建议说明:指明本文档面向的读者群,及相应的阅读意见。1.3文档*围【可选】说明:对本文的*围做阐述,本文档改动时,受到影响的*围,例如,本文引用到的用例模型,系统原型,系统测试用例等文档。1.4参考文档说明:列出本文档的所有参考文献(可以是非正式出版物),包括方案任务书、合同、批文、引用到的文件、资料及软件开发标准等。1.5术语与缩写解释说明:列出本文件中用到的专门术语的定义和缩写词的原词组,并给予解释,以便于所有读者达成共识。2综合描述2.1系统背景【可选】说明:介绍系统的预期效果、历史原因。文件状态:[√]草稿[]正式发布[]正在修改文件标识:ProjectName-当前版本:*.Y作者:完成日期:Year-Month-Day版本/状态作者参与者起止日期备注第14页,共53页技术开发管理制度2.2问题说明【可选】提供一段说明,总结此工程需要解决的问题。可以采用以下格式:2.3系统*围说明:阐述本工程“适用的业务领域〞和“不适用的业务领域〞,本产品“应当包含的内容〞和“不包含的内容〞。说清楚系统*围的好处是:(1)有助于判断什么是需求,什么不是需求;(2)可以将开发精力集中在产品*围之内;(3)有助于控制需求的变更。完整而准确的定义本产品的干系人;明确本产品所影响到的部门和业务;用图表或者文字描述产品的*围,概要的定义产品的功能。2.4干系人与用户说明【可选】2.4.1用户环境【可选】详细说明目标用户的工作环境。以下是几项建议:该任务由多少人来完成?是否总在变化?一个任务周期需要多长时间?执行每项活动要用多长时间?是否总在变化?是否有特殊的环境约束:移动、户外、乘机旅行等?目前使用的是哪些系统平台?以后会使用哪些平台?还在使用哪些应用程序?您的应用程序是否需要和这些应用程序集成?在此处可以从业务模型中摘录一些内容来概述所涉及的任务和角色等等。2.4.2干系人简档【可选】通过在下表中填写各干系人的相关信息来说明系统中的各个干系人,详尽的简档应包括各种干系人在以下方面的信息:问题是[对问题进展说明]影响[问题影响的干系人]问题的后果[该问题会导致什么后果]成功的解决方案[应列出成功解决方案的一些主要优点]代表[谁是此产品的干系人代表?(如在他处已作记录,则此处为可选。)此处只需填写**。]第15页,共53页技术开发管理制度说明[对干系人类型的简要说明。]类型[介绍干系人的技能特长、技术背景和熟练程度(即权威用户、业务用户、专家用户、初级用户等)]职责[列出干系人对所开发的系统负有的关键职责,即他们作为干系人的利益。]使用频率[该干系人使用系统的频率]意见/问题[在此处列出会阻碍成功的问题以及任何其他相关信息。]2.4.3关键的干系人/用户需要列出干系人认为现有解决方案存在的关键问题。对于列出的每个问题,需澄清以下要点:为什么会出现这一问题?目前如何解决该问题?干系人需要什么样的解决方案?务必要了解干系人或用户对解决各个问题的相对重视程度。分级和累积投票方法说明,必须解决的问题与干系人或用户希望解决的问题大有不同。2.5目标业务模型【可选】说明:新系统业务模型描述,如有相应业务模型材料了,可作为需求规格说明书的输入参考资料。2.6功能摘要总结该产品将提供的主要优点和特性,而不必涉及每个功能的细节。对功能加以组织,使客户或初次阅读该文档的其他人能够理解此功能列表。2.7功能清单及重要程度说明说明:功能名称、功能描述、重要程度。重要程度,以ABC三类来表示:A:核心功能;B:辅助功能;C:外围功能;级别,按照继承关系分为:一级,二级,三级;2.8功能与业务对照关系表说明:业务组为主编写业务需求,业务需求提交至信息技术组后,由信息技术组建立目标编号级别重要程度功能名称功能描述备注第16页,共53页技术开发管理制度系统业务模型并与业务组进展确认(本操作可选,也可由信息技术组与开发商合作建立),目标业务模型作为系统需求的输入,由信息技术组与开发商合作撰写和评审?系统需求规格书明书?。2.9假定和约束说明:列出进展本软件开发工作的假定和约束,例如:开发语言、开发期限等。格式限制说明:本项将指定由现有的标准或规则派生的要求。例如:报表格式;数据命名;财务处理;审计追踪,等等。硬件限制说明:本项包括在各种硬件约束下运行的软件要求,例如,应该包括:硬件配置的特点(接口数,指令系统等);内存储器和辅助存储器的容量。2.9.1运行环境约束说明:硬件设备、支持软件、接口、控制等方面的约束2.9.2设计约束【可选】说明:开发过程中必须使用的软件语言、软件进程需求、主要开发工具、核心技术、第三方产品等。2.9.3产品应当遵循的标准或规*说明:阐述本产品应当遵循什么标准、规*或业务规则,违反标准、规*或业务规则的产品通常不太可能被承受。3具体需求3.1功能需求3.1.1具体功能内容说明:对于每一类功能或者有时对于每一个功能,需要具体描述其输入、加工和输出的需求。业务需求目标系统业务活动(可选)功能名称名称详细要求第17页,共53页技术开发管理制度3.2非功能需求3.2.1外部接口用户接口说明:提供用户使用软件产品时的接口需求。例如,如果系统的用户通过显示终端进展操作,就必须指定如下要求:a对屏幕格式的要求说明:对界面上的各对象、类型、宽度、取值*围、数据来源、能否为空等属性进展描述。b报表或菜单的页面打印格式和内容c输入输出的需求说明:解释各输入输出数据类型,并逐项说明其媒体、格式、数值*围、精度等。对软件的数据输出及必须标明的控制输出量进展解释并举例,包括对硬拷贝报告(正常结果输出、状态输出及异常输出)以及图形或显示报告的描述。d程序功能键的可用性说明:快捷键定义等。硬件接口【可选】说明:要指出软件产品和系统硬部件之间每一个接口的逻辑特点。还可能包括如下事宜:支撑什么样的设备,如何支撑这些设备,有何约定。软件接口【可选】说明:在此要指定需使用的其他软件产品(例如,数据管理系统、操作系统或数学软件包),以及同其他应用系统之间的接口。对每一个所需的软件产品,要提供如下内容:名字、助记符、规格说明号、版本号、来源。对于每一个接口,这局部应说明与软件产品相关的接口软件的目的,并根据信息的内容和格式定义接口,但不必详细描述任何已有完整文件的接口,只要引用定义该接口的文件即可。【接口定义】下表是对一些接口的具体描述:接口名称接口描述填写接口完成的任务第18页,共53页技术开发管理制度接口类型填写是输入接口(inbound)还是输出接口(outbound)源系统填写接口输入方系统或部件目标系统填写接口输出方系统或部件厂商提供/客户化开发文件类型填写文件类型;假设通过数据库表来交互,请指明数据库及表名文件数量峰值数据量频度填写数据处理的频度复杂度批处理/人工填写接口数据的驱动模式是人工(manual)还是自动(automatic),还是都支持接口类型填写是实时接口还是批量接口等【其他系统详细信息】说明:列出所有与接口交互的外围系统的详细信息。包括输入、输出系统等系统填写与接口交互的系统名称系统类型填写是接口的数据源系统(source)还是目标系统(object)数据库填写交互系统使用的数据库及版本软件填写交互系统的软件名称架构类型交互系统的架构类型是B/S还是C/S。位置填写该软件在交互软件体系中所出的位置技术支持填写交互系统的开发商和支持商功能支持填写具体的支持商或技术团队数据归属【接口隶属系统的详细信息[可选]】系统填写接口隶属系统的名称模块隶属于具体的模块名称数据库隶属系统的数据库及版本负责人第19页,共53页技术开发管理制度控制报告【接口配置】(1)接口根底信息配置说明:接口根底信息的配置工程,描述配置的方式。(2)接口运行参数配置说明:接口运行参数的配置方式和步骤。【其他配置[可选]】说明:外围系统或相关模块的配置。通信接口【可选】说明:指定各种通信接口。例如,局部网络的协议等等。3.2.2其他非功能性需求说明:下表中的各种需求,可根据实际情况进展选择其中的一种或者几种进展描述,在表的后面是各种需求的详细解释。名称详细要求静态数值需求动态数值需求精度时间特性要求可用性可靠性可维护性平安性可移植性可扩展性兼容性...静态数值需求说明:支持的终端数;支持并行操作的用户数。动态数值需求第20页,共53页技术开发管理制度说明:欲处理的事务和任务的数量,以及在正常情况下和峰值工作条件下一定时间周期中处理的数据总量。精度说明:对该软件的输入、输出数据精度的要求,可能包括传输过程中的精度。时间特性要求说明:对于该软件的时间特性要求,如对:a.响应时间;b.更新处理时间;c.数据的转换和传送时间;d.解题时间等要求。数据管理要求【可选】说明:需要管理的文卷和记录的个数、表和文卷的大小规模,要按可预见的增长对数据及其分量的存储要求做出估算。可用性指出普通用户和高级用户要高效地执行特定操作所需的培训时间,指出典型任务的可评测任务次数或根据用户或喜欢的其他系统确定新系统的可用性需求性能可靠性指出可用时间百分比(**.**%)、使用小时数、维护访问权、降级模式操作等。平均故障间隔时间(MTBF)。平均修复时间(MTTR)—系统在发生故障后可以暂停运行的时间。指出系统输出要求具备的精细度(分辨率)和准确度(按照*一的标准)。3.2.3文档需求说明:主要是在线用户手册与帮助系统,也包括其他的文档3.2.4第三方产品【可选】说明:使用到的第三方产品相关的使用许可、使用限制、接口标准。3.3数据字典说明:把相关的数据抽取出来统一维护,在其他章节如有类似信息描述,则关联到数据字典的相关局部并加辅助说明,如:引用到的字段等。4补充资料【可选】第21页,共53页技术开发管理制度4.1待确定的问题列表【可选】需求标题1调查方式调查人调查对象时间、地点需求信息记录第22页,共53页技术开发管理制度四需求变更申请记录号:工程:类型:开发工程工程负责人:变更申请人:申请部门:申请日期:变更内容变更的内容及其理由说明变更的内容及变更的理由,如果变更为业务组提出,则业务组填写;如果变更为为信息技术组提出,则信息技术组填写;变更的系统及版本说明变更所涉及的工作产品及其当前版本,如果变更为业务组提出,则业务组填写;如果变更为为信息技术组提出,则信息技术组填写;对业务及其接口的影响分析需求变更引起的业务变更、业务接口的变更,业务组填写业务负责人意见:同意不同意签字:日期:第23页,共53页技术开发管理制度变更结果变更分析对相关的资源影响分析需求变更对人员、开发设备和目标设备的影响,仅信息技术组填写风险分析分析需求变更的风险,仅信息技术组填写对其他系统或接口的影响分析需求变更引起的系统变更、其他系统或接口的变更,仅信息技术组填写对开发工作量、进度和本钱影响估计需求变更对开发工作量和进度的影响,需说明本次变更工作量/本钱是否超过本工程总开发工作量/总本钱的1%?仅信息技术组填写信息技术部审批意见信息技术组负责人意见:同意不同意指定验证人员:签字:日期:处经理意见:签字:日期:同意不同意汇报上级上级经理意见:同意不同意签字:日期:变更结果变更的系统及版本说明变更后的工作产品签字:日期:变更验证验证变更结果完整性是否正确性是否第24页,共53页技术开发管理制度附加变更是否版本和名称是否验证人意见:符合要求不符合要求签字:日期:第25页,共53页技术开发管理制度五工程方案书版本历史1文档介绍1.1文档目的1.2文档*围1.3参考文献提示:列出本文档的所有参考文献(可以是非正式出版物),格式如下:[标识符]作者,文献名称,出版单位(或归属单位),日期例如:[AAA]作者,?立项建议书?,机构名称,日期1.5术语与缩写解释2工程介绍2.1工程*围提示:(1)用简练的语言说明本工程“是什么〞,“说明用途〞。(2)说明本工程“应当包含的内容〞和“不包含的内容〞。文件状态:[√]草稿[]正式发布[]正在修改文件标识:ProjectName-当前版本:*.Y作者:完成日期:Year-Month-Day版本/状态作者参与者起止日期备注缩写、术语解释第26页,共53页技术开发管理制度2.2工程目标提示:给出“清晰的〞、“可实现〞、“可验证〞的目标。2.3客户与最终用户介绍提示:请说明本工程的客户、用户及其相关责任人是谁,描述最终用户的特征。2.4约束提示:(1)请说明在工程开发过程中应当遵循的标准或规*(2)请说明相关工程可能对本工程造成的影响。(3)说明一些假设和依赖。3工程过程定义3.1软件生命周期模型提示:简要描述、绘制本工程的软件生命周期模型。3.2工程规*提示:描述工程需遵循的规*,例如:编码规*。此处可以表现为编码规*的。3.3方法与工具提示:说明在过程中将采用的方法与工具。例如采用RationalRose进展面向对象分析与设计,采用VisualSourceSafe进展配置管理,采用MicrosoftOffice制作文档。4里程碑方案5资源方案5.1人力资源方案提示:制定本工程的角色职责表,并为的工程成员分配角色(一个人可以兼多个角色)。方法与工具用途VisualSourceSafe配置管理...序号里程碑名称开场日期完毕日期工作成果备注角色职责人员**工作说明第27页,共53页技术开发管理制度高层领导工程经理需求分析员系统设计员程序员测试员...5.2软硬件资源方案提示:分析工程开发、测试、运行所需的软硬件资源和关键计算机资源(会影响软件产品的性能的CPU、内存、带宽等内容),主要内容包括:资源级别(分为“关键〞、“普通〞两种)详细配置获取方式(如“已经存在〞、“可以借用〞或“需要购置〞等)与获取时间使用说明(如“谁〞在“什么〞时候使用)软硬件资源名称级别详细配置获取方式与时间使用说明关键关键普通...6文档交付列表7风险管理方案提示:以下是各个列标题的解释。约定在工程中的风险管理方案,例如:风险识别频度、风险跟踪频度等。风险级别:确定风险的严重性、可能性、风险系数风险描述:缓解方案或者应急方案。序号交付文档名称交付日期备注风险编号风险级别风险描述缓解方案应急方案第28页,共53页技术开发管理制度严重性(1-5)可能性(%)风险系数(严重性*可能性)8沟通方案9工程进度方案甲方代表乙方代表沟通方式沟通频率/时间期望结果第29页,共53页技术开发管理制度六工程方案变更说明工程名称工程方案变更申请申请日期输入名称,版本,完成日期等信息审批意见:签字,日期审批意见:签字,日期审批意见:签字,日期输入名称,版本,完成日期等信息申请变更的?工程方案?变更的内容及其理由评估方案变更将对工程造成的影响工程负责人签字处经理审批信息技术部负责人审批业务部门意见变更后的?工程方案?工程负责人签字变更申请的审批意见更改工程方案第30页,共53页技术开发管理制度七设计说明书版本历史文件状态:[√]草稿[]正式发布[]正在修改文件标识:ProjectName-Module-Design当前版本:*.Y作者:完成日期:Year-Month-Day版本/状态作者参与者起止日期备注第31页,共53页1引言1.1编写目的说明编写这份详细设计说明书的目的,指出预期的读者。1.2背景说明:待开发软件系统的名称;本工程的任务提出者、开发者、用户和运行该程序系统的计算中心。1.3定义列出本文件中用到专门术语的定义和外文首字母组词的原词组。1.4参考资料列出有关的参考资料,如:本工程的经核准的方案任务书或合同、上级机关的批文;属于本工程的其他已发表的文件;本文件中各处引用到的文件资料,包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位,说明能够取得这些文件的来源。2程序系统的构造用一系列图表列出本程序系统内的每个程序(包括每个模块和子程序)的名称、标识符和它们之间的层次构造关系。3程序1(标识符)设计说明从本章开场,逐个地给出各个层次中的每个程序的设计考虑。以下给出的提纲是针对一般情况的。对于一个具体的模块,尤其是层次比较低的模块或子程序,其很多条目的内容往往与它所隶属的上一层模块的对应条目的内容一样,在这种情况下,只要简单地说明这一点即可。3.1程序描述给出对该程序的简要描述,主要说明安排设计本程序的目的意义,并且,还要说明本程序的特点(如是常驻内存还是非常驻?是否子程序?是可重人的还是不可重人的?有无覆盖要求?是顺序处理还是并发处理等)。3.2功能说明该程序应具有的功能,可采用IPO图(即输入一处理一输出图)的形式。3.3性能说明对该程序的全部性能要求,包括对精度、灵活性和时间特性的要求。第32页,共53页信息技术管理制度3.4输人项给出对每一个输入项的特性,包括名称、标识、数据的类型和格式、数据值的有效*围、输入的方式。数量和频度、输入媒体、输入数据的来源和平安**条件等等。3.5输出项给出对每一个输出项的特性,包括名称、标识、数据的类型和格式,数据值的有效*围,输出的形式、数量和频度,输出媒体、对输出图形及符号的说明、平安**条件等等。3.6算法详细说明本程序所选用的算法,具体的计算公式和计算步骤。3.7流程逻辑用图表(例如流程图、判定表等)辅以必要的说明来表示本程序的逻辑流程。3.8接口用图的形式说明本程序所隶属的上一层模块及隶属于本程序的下一层模块、子程序,说明参数赋值和调用方式,说明与本程序相直接关联的数据构造(数据库、数据文卷)。3.9存储分配根据需要,说明本程序的存储分配。3.10

注释设计说明准备在本程序中安排的注释,如:加在模块首部的注释;加在各分枝点处的注释;对各变量的功能、*围、缺省条件等所加的注释;对使用的逻辑所加的注释等等。3.11

限制条件说明本程序运行中所受到的限制条件。3.12

测试方案说明对本程序进展单体测试的方案,包括对测试的技术要求、输入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等的规定。3.13尚未解决的问题说明在本程序的设计**未解决而设计者认为在软件完成之前应解决的问题。4程序2(标识符)设计说明用类似F.3的方式,说明第2个程序乃至第N个程序的设计考虑。第33页,共53页信息技术管理制度八单元测试用例1测试*围说明:本用例测试的功能点。2测试环境环境1:环境2:3数据准备说明:可以引用适当的,如E*CEL文件、文本文件等扁平文件等,这些文件内存放着测试准备的数据。测试用例功能1信息技术管理制度硬件环境:效劳器端:客户端:软件环境:效劳器端:客户端:网络环境:测试编号功能模块-子模块-编号测试工程模块功能-子模块功能用例描述描述测试上述功能的测试点依赖描述无环境及初始数据环境1,填写用到的各种测试数据的名称依赖样例测试本用例依赖的相关用例名称序号前置条件测试子项执行步骤预期结果实际结果备注第34页,共53页信息技术管理制度测试序号填写本用例运行的前置条件。如登陆、权限、设备就绪等;说明测试的根本流还是备选流;要求测试遍历所有的备选流;详细列出各个用例角色的操作的动作。对应每一步的预测结果;对应每一个执行步骤的实际结果;填写与测试相关联的核对点、检查点。第35页,共53页九设计评审报告信息技术管理制度文件状态:[√]草稿[]正式发布[]正在修改文件标识:ProjectName-当前版本:*.Y作者:完成日期:Year-Month-Day版本历史版本/状态作者参与者起止日期备注1.根本信息提示:由评审主持人或评审员填写此表格。待评审的工作成果工作成果名称,标识符,版本,作者,时间...技术评审方式(正式评审)或者(走查)评审时间评审地点参加技术评审的人员类别名字工作单位职称、职务:主持人评审小组成员记录员第36页,共53页2.缺陷识别和跟踪信息技术管理制度评审问题跟踪表编号问题描述问题类型严重性提交者提交日期问题处理负责人解决措施/原因说明问题解决状实际关闭日问题关闭验备注态期证人1233.评审结论与意见提示:由主持人或评审员填写此表格。[]工作成果合格,“无需修改〞或者“需要轻微修改但不必再审核〞。[√]工作成果根本合格,需要作少量的修改,之后通过审核即可。[]工作成果不合格,需要作比较大的修改,之后必须重新对其评审。评审结论意见负责人签字签字:日期:第37页,共53页十系统/用户测试方案信息技术管理制度文件状态:[√]草稿[]正式发布[]正在修改文件标识:当前版本:作者:完成日期:Year-Month-Day版本历史版本/状态作者参与者起止日期备注1.测试*围与主要内容提示:系统测试小组应当根据工程的特征确定测试*围与内容。一般地,系统测试的主要内容包括功能测试、强健性测试、性能测试、用户界面测试、平安性(security)测试、安装与反安装测试等。2.测试方法提示:例如黑盒测试和白盒测试。3.测试环境与测试辅助工具环境工具设备配置名称/类型备注效劳器软件硬件客户端软件硬件网络类型工具开发商版本测试管理缺陷跟踪用于功能性测试的工具用于性能测试的工具第38页,共53页信息技术管理制度测试覆盖监测器或评测器4.测试进度方案5.测试完成准则提示:对于非严格系统可以采用“基于测试用例〞的准则:(1)功能性测试用例通过率到达100%;(2)非功能性测试用例通过率到达95%时。对于严格系统,应当补充“基于BUG密度〞的规则:相邻n个CPU小时内“测试期BUG密度〞全部低于*个值m。例如n大于10,m小于等于1。最后一次回归测试二类缺陷数量为零,用例外非常规缺陷数量小于等于2个/万行程序;测试用例功能点覆盖率100%;6.BUG管理与改错方案提示:根据所采用的BUG管理工具确定:(1)BUG管理流程,(2)BUG修改流程。定义BUG修改约定,例如:不同级别的BUG必须在几日内处理完成。7.附录.本方案审批意见任务人员任务开场日期完毕日期制定测试方案设计测试实施测试执行测试对测试进展评估工程经理审批意见:签字日期第39页,共53页十一系统/用户测试报告1.根本信息信息技术管理制度测试依据例如:参照标准、客户需求、需求规格说明书、测试用例等测试*围测试验收标准测试环境描述测试驱动程序描述提示:可以把测试驱动程序当作测试人员测试时间须注明每次回归测试的时间测试工具2.实况记录3.测试总评价根据对测试结果提出一个关于软件能力的全面分析,需标明遗留的主要缺陷、局限性和软件的约束限制等,并提出软件测试过程中程序中的缺乏。根据测试标准及测试结果,综合评价软件的开发是否已到达预定目标。4.缺陷修改记录提示:如果采用了缺陷管理工具,能自动产生缺陷报表的话,则无需本表。测试人员签字/日期:第40页,共53页模块测试用例编号期望结果测试结果缺陷密度是否执行了回归测试缺陷名称缺陷类型严重程度模块原因驻留时间解决方案...十二试运行方案信息技术管理制度文件状态:[√]草稿[]正式发布[]正在修改文件标识:ProjectName-TestRun-PLAN当前版本:*.Y作者:完成日期:Year-Month-Day版本历史版本/状态作者参与者起止日期备注1.试运行目标提示:说明本次试运行的主要内容与目标(必须是可以验证的)。2.工作条件提示:说明试运行地点、参加人员、软硬件设施、经费等要求。3.应递交的工作成果4.进度表提示:(1)用MicrosoftProject制作进度表(GanttChart)插入此处或者参照此表制作一份进度表。5.可能存在的困难与风险提示:指出可能存在的困难和风险,制定应急方案以应对突发事件。工作成果名称预计完成时间试运行报告报错趋势分析报告......任务名称及其描述开场时间完毕时间参加人员任务1任务2...第41页,共53页附录:本方案审批意见提示:工程经理或者技术负责人根据工程方案以及现实情况(如可以支配的人力资源),审批该?试运行方案?。信息技术管理制度工程经理或试运行负责人审批意见:签字日期第42页,共53页十三数据迁移方案1.数据迁移的重要事件和里程碑日期2.数据迁移前的备份要求3.数据迁移测试结果清单4.转换工作进度表提示:(1)用MicrosoftProject制作进度表(GanttChart),插入此处或作为。(2)或者在此处用表格制作一份进度表,例如:5.转换操作步骤以及问题处理步骤6.数据核对方案7.数据迁移的需求和实施方案8.应急预案及回退方案1).分析引发转换失败的潜在原因提示:说明转换失败的几类原因,考虑人员、软硬件设施、经费等因素。2).预防措施提示:针对转换失败的几类原因,制定预防措施。3).事件处理及回退方案提示:在突发事件出现时的应对策略,应从人员组织、流程制定等方面考虑。4).组织机制提示:建立应急处理小组成员,明确职责到人。8.培训方案说明培训内容,时间,地点,培训讲师等信息。9.附录:本方案审批意见信息技术管理制度任务名称及其描述开场时间完毕时间参加人员任务1任务2...应急处理人员角色职责第43页,共53页信息技术管理制度工程负责人审批意见:签字日期信息技术部审批意见签字日期业务部门审批意见签字日期第44页,共53页信息技术管理制度第45页,共53页十四数据迁移报告1.背景介绍提示:介绍系统转换的背景情况。2.数据迁移目标提示:说明本次数据迁移的主要内容与目标。3.数据准备提示:所准备进展转换的数据情况描述以及数据来源部门的审批结果4.数据迁移实录提示:回忆系统上线各阶段工作,大体步骤5.数据迁移后数据核对过程和结论提示:说明本次数据迁移后进展数据核对的过程以及结论。包含主文件检查、转换前后