软件项目管理规范.doc
《软件项目管理规范.doc》由会员分享,可在线阅读,更多相关《软件项目管理规范.doc(31页珍藏版)》请在咨信网上搜索。
1、疾病管理平台软件开发管理规范文件编号: BD-jsgf002 生效日期: 2016.2.19受控编号:版次:Ver1.0修改状态:总页数30正文28附录0编制:李杰审核:王怀锋批准:付光伟山东诺安诺泰信息系统有限公司软件开发行为规范为了把公司已经发布的软件开发过程规范有效地运作于产品开发活动中,把各种规范“逐步形成工程师的作业规范”,特制定本软件开发行为规范,以达到过程控制的目的。与软件开发相关的所有人员,包括各级经理和工程师都必须遵守本软件开发行为规范。对违反规范的开发行为,必须按照有关管理规定进行处罚。本软件开发行为规范的内容包括:软件需求分析、软件项目计划、概要设计、详细设计、编码、需求
2、管理、配置管理、软件质量保证、数据度量和分析等。 本软件开发行为规范,采用以下的术语描述: 规则:在软件开发过程中强制必须遵守的行为规范。 建议:软件开发过程中必须加以考虑的行为规范。 说明:对此规则或建议进行必要的解释。 示例:对此规则或建议从正或反两个方面给出例子。 本软件开发过程行为规范由研究技术管理处负责解释和维护。目 录1 软件需求分析52 软件项目计划93 概要设计114 详细设计145 编码186 需求管理197 软件配置管理218 软件质量保证239 数据度量和分析251 软件需求分析1-1:软件需求分析必须在产品需求规格的基础上进行,并保证完全实现产品需求规格的定义。1-2:
3、当产品的需求规格发生变更时,必须修订软件需求规格文档。软件需求规格的变更必须经过评审,并保存评审记录。1-3:必须对软件需求规格文档进行正规检视。1-4:软件需求分析过程活动结束前,必须经过评审,并保存评审记录。1-5:在对软件需求规格文档的正规检视或评审时,必须检查软件需求规格文档中需求的清晰性、完备性、兼容性、一致性、正确性、可行性、易修改性、健壮性、易追溯性、易理解性、易测试性和可验证性、性能、功能、接口、数据、可维护性等内容。说明:参考建议1-1到1-16。1-1:采用以下检查表检查软件需求规格文档中需求的清晰性。序号问题1所有定义、实现方法是否清楚地表达了用户的原始要求?2在功能实现
4、过程、方法和技术要求的描述上,是否没有背离了功能的实际要求?3是否没有不能理解或造成误解的描述 ?1-2:采用以下检查表检查软件需求规格文档中需求的完备性。序号问题1需求定义中是否包含了有关文件(指质量手册、质量计划以及其它有关文件)种所规定的需求定义所应该包含的所有内容?2需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有需求?3功能性需求是否覆盖了所有非正常情况的处理?4是否对各种操作模式(如正常、非正常、有干扰等)下的环境条件都作了规定?5是否对所有功能与时间因素有关的方面都作了考虑?6是否标识出了所有与时间因素有关的功能?它们的时间准则是否都说明了?时间准则的最大、最小执行
5、时间是否都定义了?7是否标识并定义了在将来可能会变化的需求?8是否定义了系统所有的输入?9是否标识清楚了系统输入的来源?10是否标识出了系统的输出?11是否说明了系统输入、输出的类型?12是否说明了系统输入、输出的值域、单位、格式等?13是否说明了如何进行系统输入的合法性检查?14是否定义了系统输入、输出的精度?15是否定义了系统性能的各个方面?16在不同负载情况下,是否规定了系统的处理能力?17在不同情况下,是否规定了系统的响应时间?18是否充分定义了关于人机界面的需求?19是否对需求定义进行了可行性分析和相关文件(资料)是否已归档?20是否对影响需求实现的因素进行了调查,调查结果是否已归档
6、?21是否有经济效益分析,分析结果是否已归档?22是否详细描述了有关硬件、软件、操作人员、操作过程等方面的安全性?23是否评估了本项目对用户、其它系统、环境的影响特性?24是否按完成时间、重要性对系统功能、外部接口、性能进行了优先排序?1-3:采用以下检查表检查软件需求规格文档中需求的兼容性。序号问题1界面需求是否使软硬件系统具有兼容性?2需求定义的文档是否满足项目文档编写标准?在矛盾时,是否有适当的标准可供选择?1-4:采用以下检查表检查软件需求规格文档中需求的一致性。序号问题1各个需求之间是否一致?是否有冲突和矛盾?2所规定的模型、算法和数值方法是否相容?3是否使用了标准的术语和定义形式?
7、4需求是否与其软硬件操作环境相容?5是否说明了软件对其系统和环境的影响?6是否说明了环境对软件的影响?7所采用的技术是否与用户要求的技术一致?1-5:采用以下检查表检查软件需求规格文档中需求的正确性。序号问题1需求定义是否满足标准的要求?2算法和规则是否有科技文献或其它文献作为基础?3是否定义了对在错误、风险分析中所标识出的各种故障模式和错误类型所需的反应?4是否参照了有关的标准?5是否对每一个需求都给出了理由?理由是否充分?6对设计和实现的限制是否都有论证?1-6:采用以下检查表检查软件需求规格文档中需求的可行性。序号问题1需求定义是否使软件的设计、实现、操作和维护都可行?2所规定的模型、数
8、值方法和算法是否对待解决问题合适?是否能够在相应的限制条件下实现?3是否能够达到关于质量的要求?1-7:采用以下检查表检查软件需求规格文档中需求的易修改性。序号问题1对需求定义的描述是否易于修改(如是否采用良好的结构和交叉引用表等)?2是否有冗余的信息?是否一个需求被定义了多次?1-8:采用以下检查表检查软件需求规格文档中需求的健壮性。序号问题1是否有容错的需求?1-9:采用以下检查表检查软件需求规格文档中需求的易追溯性。序号问题1是否可从上一阶段的文档中找到需求定义中的相应内容?2需求定义是否明确地表明前阶段中提出的有关需求和设计限制都已被覆盖了?3需求定义是否便于向后继开发阶段查找信息1-
9、10:采用以下检查表检查软件需求规格文档中需求的易理解性。序号问题1是否每一个需求都只有一种解释?2功能性需求是否以模块方式描述的?是否明确地标识出了其功能?3是否有术语定义一览表?4是否使用了形式化或半形式化的语言?5语言是否有歧义性?6需求定义中是否只包含了必须的实现细节而不包含不必要的实现细节?是否过分细致了?7需求定义是否足够清楚和明确使其能够作为开发设计规约和功能性测试数据的基础?8需求定义的描述是否将对程序的需求和所提供的其它信息分离开来了?1-11:采用以下检查表检查软件需求规格文档中需求的易测试性和可验证性。序号问题1需求是否可以验证(即是否可以检验软件是否满足了需求)?2是否
10、对每一个需求都指定了验证过程?3数学函数的定义是否使用了精确定义的语法和语义符号?1-12:采用以下检查表检查软件需求规格文档中的性能需求描述。序号问题是否精确的描述了所有的性能需求和可容忍的性能降低程度?对每一个性能应包含两方面的内容:1 a. 在最坏情况的执行结果 2 b. 本性能失效后,对系统产生的影响1-13:采用以下检查表检查软件需求规格文档中功能需求描述。序号问题1是否清楚、明确地描述了所有的功能?2所有已描述的功能是否是必须的?是否能满足任务书或系统目标的要求?1-14:采用以下检查表检查软件需求规格文档中的接口需求描述。序号问题1是否清楚地定义了所有的接口?3所有接口是否必须?
11、各接口间的关系是否一致、正确?1-15:采用以下检查表检查软件需求规格文档中的数据需求描述。序号问题1在某异常数据(如条件、标志等)下,是否有真正没有考虑到的结果?2对异常数据产生的结果是否作了精确的描述?1-16:采用以下检查表检查软件需求规格文档中的可维护性需求描述。序号问题1需求定义中是否包括了可行的系统维护方法?2软件系统间的关系是否是松耦合的(即能否保证在对某部分修改后,产生最小的连锁效应)?2 软件项目计划2-1:软件项目计划必须以产品/软件的需求规格为基础。当发生需求更改时,必须修订软件开发计划。说明:软件项目计划必须依据需求规格进行制定。项目计划中的工作产品和工作任务应保证能完
12、全实现需求规格的定义。当需求更改时,必须考虑需求更改的相关性,修订相应软件开发计划。2-1:制定软件项目计划的活动制定,必须遵守“软件项目计划规范”。2-2:软件经理对软件项目计划的制定和结果负责。2-3:软件经理和相关参与软件项目计划的制定和评审的人员,在参与计划制定之前必须经过软件工程和软件项目计划制定流程的培训。2-2:对于软件项目计划中各项工作产品和工作任务,必须进行规模和工作量的软件估计,并在软件项目计划文档中记录估计的方法和估计数据。说明:参考建议2-4到2-8。2-4:可以使用PERT统计估计、专家判定平均法、经验类比估计、公式计算等方法,或以上方法的组合,进行软件估计。示例:P
13、ERT统计估计和经验类比估计的结合PERT统计估计值 (最大估计4期望估计最小估计/ 6估计记录如下:工作产品任务最大估计期望估计(根据经验类比获得)最小估计PERT估计规模工作量规模工作量规模工作量规模工作量XX版本(增加XX特性话统模块概要设计文档页数:45;增加、修改模块设计数目:1212天文档页数:42;增加、修改模块设计数目:1010天文档页数:30;增加、修改模块设计数目:55天文档页数:41;增加、修改模块设计数目:109.5天期望估计值是根据XX版本的话统模块设计的数据获得。2-5:对某项工作产品和任务的软件,同时采用两种或以上的方法进行估计,以避免一种方法的偏差。2-6:尽量
14、采用历史经验数据进行软件估计。2-7:参照“软件估计指导书”进行软件估计。2-8:软件估计对应项目的任务分解结构进行。说明:软件估计对于项目的任务分解结构对应得越清晰、越细致,相应的估计越准确。2-9:在“软件项目计划”中必须包括项目管理活动的计划。2-10:在“软件项目计划”中包括软件重用计划。包括重用软件部件的计划和开发可重用软件部件的计划。2-11: 在“软件项目计划”包括人员的培训计划。说明:项目人员计划包括需要的人员类型、数量和技术等级的要求,相关人员的开始工作时间、工作周期、接受培训的计划等。2-12:对软件项目进行风险分析与评估。说明:可能存在的风险领域含:需求的不明确和变更、外
15、部的限制与对外的依赖、人力资源的到位情况、人力资源的技术等级满足要求状况、技术问题等。 对风险的分析与评估实践包括:从已知的情况推导出潜在风险;对风险进行分析,得出:潜在风险可能引发的问题的影响、潜在风险发生的可能性大小、风险发生的时间段等;排列风险的重点次序;对风险记录成文件(属于软件项目计划中的一部分);风险经受风险影响人审核,并取得他的同意;根据需要,在开发过程中对风险文档进行维护和修订。2-3:对应工作任务,制定项目的文档计划。2-4:软件项目计划中应该包括正规检视活动计划、软件质量保证计划、软件配置管理计划。软件质量保证计划和软件配置管理计划可以和软件项目计划在同一份文档中,也可以分
16、开为三份文档。说明:参考建议2-13。2-13:软件质量保证计划和软件配置管理计划作为独立的计划文档。2-14:软件项目计划必须是整个项目开发过程的计划,包括测试。2-15:测试经理对照整个开发计划建立软件验证与确认计划。软件验证与确认计划可作为独立的计划文档。2-5:必须对项目工作进行分解,确定项目的工作任务,任务的责任人、资源要求、时间要求、项目的进度。2-6:必须分析任务之间的依赖性,确定并明确标识项目的关键路径。2-7:“软件项目计划”必须按照文档模板的要求编写。项目组可根据项目的实际情况,对文档模板中的内容进行裁减。项目组对文档模板内容的裁减必须得到上级管理部门(包括产品计划处、软件
17、工程组SEPG)的审核批准。2-8:软件项目计划必须经过评审。说明:参考建议2-16,。2-16:软件项目计划的评审采用以下检查表。序号问题1软件项目计划是否完全反映(对应)“软件需求说明书”里的需求?2软件项目计划是否有开发方法的说明?3软件项目计划是否有资源需求的说明?4软件项目计划是否包含风险管理计划?5软件项目计划是否包含了版本发布的机制?6软件项目计划是否标识了所有必须的培训计划?7软件项目计划是否标识了所有内部和外部的传递关系?8软件项目计划是否标明了项目的依赖关系?9软件项目计划是否标明了角色和职责?10软件项目计划是否标明了汇报的机制?11软件项目计划是否说明了跟踪和监控机制?
18、12软件项目计划是否包含“软件质量保证计划”和“软件配置管理计划”?13软件项目计划是否包含项目开发使用的工具?14软件项目计划是否包含项目的各里程碑的说明?15进度中是否标明了软件项目计划的关键路径?2-17:参加“软件项目计划”评审的人员,除软件经理和项目组人员外,必须有产品经理、上级管理部门(包括软件工程组SEPG)、SQA人员。2-18:“软件项目计划”通过评审后,软件经理组织相关人员对任务进行承诺,签定工作任务书。2-9:必须对“软件项目计划”进行配置管理,“软件项目计划”的更改必须经过评审。2-10:在开发活动中,必须按照项目跟踪与监控计划和体制,对照“软件项目计划”,跟踪项目开发
19、的实际结果和性能。2-11:当实际结果和“软件项目计划”发生偏离时,必须进行分析,根据分析结果标明纠正措施。必要的情况下,要及时修订“软件项目计划”。2-12:在软件项目跟踪监控活动中,必须定期进行总结和评审,撰写开发状态报告。2-19:根据项目的特点,报告的周期可以为周、双周、月。2-13:在软件开发各里程碑阶段结束前,必须进行阶段评审,对软件项目进行重估计,必要的情况下修订“软件项目计划”。 2-20:必须提供相应资源,包括工具和人员等,进行软件项目计划和项目跟踪监控活动。2-14:在软件项目计划和项目跟踪监控过程活动中,必须进行数据度量和分析。说明:参见“9. 数据度量和分析”。仅供内部
20、使用11软件开发行为规范3 概要设计3 概要设计3-1:概要设计要以软件需求规格为基础,必须保证需要实现的需求规格已经被设计。3-2:当需求规格发生变更时,必须修订相关概要设计文档。3-3:在概要设计文档或需求管理文档中,必须记录、验证需求和概要设计的跟踪关系。说明:需求和概要设计的跟踪关系可参考建议3-1。3-1:采用需求、子系统、模块的跟踪矩阵表记录需求和概要设计的跟踪关系。3-4:必须保证概要设计文档和代码的一致性。当发生设计更改时,必须修订相应设计文档。3-5:必须对概要设计文档进行正规检视。3-6:概要设计过程结束前,必须通过评审,并保存评审记录。3-7:设计更改必须经过相关评审,并
21、保存评审记录。3-8:对概要设计文档的正规检视或评审,必须检查概要设计文档的清晰性、完备性、规范性、一致性、正确性、数据、功能性、接口、详细程度、可维护性、性能、可靠性、可测试性、可追溯性。说明:参考建议3-2。3-2:采用以下检查表检查概要设计文档的清晰性。序号问题1程序结构,包括数据流、控制流和接口的描述是否清楚?3-3:采用以下检查表检查概要设计文档的完备性。序号问题1设计目标是否定义?2需求规格评审中不完整的需求(TBD)是否都已经解决?3如果以前定义的不完整的需求(TBD)发生了改变,本设计是否能够支持?4是否对不完整需求(TBD)的影响进行了评估?5对有可能不能实现的设计是否有风险
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 项目 管理 规范
1、咨信平台为文档C2C交易模式,即用户上传的文档直接被用户下载,收益归上传人(含作者)所有;本站仅是提供信息存储空间和展示预览,仅对用户上传内容的表现方式做保护处理,对上载内容不做任何修改或编辑。所展示的作品文档包括内容和图片全部来源于网络用户和作者上传投稿,我们不确定上传用户享有完全著作权,根据《信息网络传播权保护条例》,如果侵犯了您的版权、权益或隐私,请联系我们,核实后会尽快下架及时删除,并可随时和客服了解处理情况,尊重保护知识产权我们共同努力。
2、文档的总页数、文档格式和文档大小以系统显示为准(内容中显示的页数不一定正确),网站客服只以系统显示的页数、文件格式、文档大小作为仲裁依据,平台无法对文档的真实性、完整性、权威性、准确性、专业性及其观点立场做任何保证或承诺,下载前须认真查看,确认无误后再购买,务必慎重购买;若有违法违纪将进行移交司法处理,若涉侵权平台将进行基本处罚并下架。
3、本站所有内容均由用户上传,付费前请自行鉴别,如您付费,意味着您已接受本站规则且自行承担风险,本站不进行额外附加服务,虚拟产品一经售出概不退款(未进行购买下载可退充值款),文档一经付费(服务费)、不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
4、如你看到网页展示的文档有www.zixin.com.cn水印,是因预览和防盗链等技术需要对页面进行转换压缩成图而已,我们并不对上传的文档进行任何编辑或修改,文档下载后都不会有水印标识(原文档上传前个别存留的除外),下载后原文更清晰;试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓;PPT和DOC文档可被视为“模板”,允许上传人保留章节、目录结构的情况下删减部份的内容;PDF文档不管是原文档转换或图片扫描而得,本站不作要求视为允许,下载前自行私信或留言给上传者【精****】。
5、本文档所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用;网站提供的党政主题相关内容(国旗、国徽、党徽--等)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
6、文档遇到问题,请及时私信或留言给本站上传会员【精****】,需本站解决可联系【 微信客服】、【 QQ客服】,若有其他问题请点击或扫码反馈【 服务填表】;文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“【 版权申诉】”(推荐),意见反馈和侵权处理邮箱:1219186828@qq.com;也可以拔打客服电话:4008-655-100;投诉/维权电话:4009-655-100。