下载文档原格式
华为编程规范华为是一家世界知名的信息通信技术（ICT）解决方案供应商，为全球超过170个国家和地区的企业和消费者提供产品和服务。
在华为的软件开发过程中，编程规范起着至关重要的作用。
良好的编程规范有助于提高代码的质量和可维护性，减少错误和调试时间，提高开发效率。
以下是华为编程规范的一些核心要点：1. 命名规范：变量、函数、类等命名应具有清晰的含义，并遵循驼峰命名法。
变量和函数名应尽量简短明了，避免使用无意义的名字。
同时，要避免使用拼音或缩写，提高代码的可读性。
2. 注释规范：良好的注释是代码可读性的重要组成部分。
应在需要解释的地方进行注释，对于复杂的算法和逻辑，要详细解释思路和实现方法。
此外，对于代码片段的用途，也可以加上简短的注释。
注释应使用英文，避免使用拼音或其他不常见的语言。
3. 缩进和空格：合理的缩进和空格可以提高代码的可读性。
在华为的编程规范中，使用四个空格作为一个缩进层级。
在运算符和逗号等地方留有适当的空格，使代码更易于阅读。
4. 函数规范：函数应尽量简短，一个函数应有一个明确的目的。
函数命名要具有清晰的语义，能够准确描述函数的功能。
参数应尽量避免过多，遵循最小化设计原则。
5. 异常处理：在代码中应该考虑到可能出现的异常情况，并进行相应的处理。
捕获异常后，应该写明异常类型，并书写明确的处理逻辑。
6. 安全性考虑：在编写代码时，应始终考虑安全性。
避免使用已知存在安全漏洞的函数和方法，对于输入的数据进行合理的校验和过滤，防止代码被恶意攻击者利用。
7. 代码格式化：代码格式化可以提高代码的可读性，使代码更易于维护。
在华为的编程规范中，要求使用一致的缩进和空格，合理分行和对齐，并采用一致的命名风格。
8. 可移植性：考虑到不同平台和操作系统的差异，编写代码时应注重可移植性。
避免使用与操作系统和平台相关的特性和函数，尽量使用标准库和接口。
9. 性能优化：在编写代码时，应注重性能优化。
避免不必要的计算和内存开销，合理选择数据结构和算法。
开发部工程师工作指导及规范一．目的:为引导工程师养成良好的工作习惯，指导其以正确的方法展开工作，提高综合业务素质，增强工作责任感，并使本岗位评估明了、公平，特制定本工作指导及规范。
二. 适用范围：本公司研发部硬件工程师。
三. 职责范围：1）在已确定的项目组内，承担所分配的该部分开发工作。
2）对本人工作负责，并以积极合作的态度达成项目组全体成功。
3）对本人负责的该部分的产品开发过程、输出（含样机及各种文件）和进度负责，保证其符合性、适应性和及时性，满足本公司其他部门和客户对产品开发输出的要求。
4）对本人负责的该部分的产品所需部件提出要求，并对样品进行测试和认可。
5）负责协助制造部进行新产品试产和问题跟进至产品顺利量产。
并对今后批量生产中需研发部解决的问题进行分析，验证和确认。
6）对本人负责范围内的以及使用的仪器、工具、办公用品、材料妥善保存并合理使用；保持本人负责范围内工作台面整洁干净；借阅资料及时归还。
7）负责协助及完成研发部经理或项目负责人临时交办事项。
四. 日常工作程序及基本规范:1.根据本人前一天拟定的当日工作计划有序的开展各项工作。
2.工作交流中礼貌用语，尽量将所需表达问题清晰完整地表达出来，对于技术问题务必注意前提条件及现象叙述完整，指向内容具体清晰；交流沟通时应从对方角度审查意思是否已表达清楚。
对于上级安排要求当日回复。
3.电子文件归档时总体按项目分类。
对于与开发和生产具有指导性的输入文件和输出文件应单独存入My Document。
2) 电子文件存放规范:⑴ 项目文件存放选择一个系统盘之外的硬盘作为工作硬盘，命名为Work Disk。
每个项目开始时，在工作硬盘上新建相应工作目录。
使用项目名称命名文件夹。
用以存放一切和项目有关的文件。
如使用Protel99等包含项目工作文件的作图工具，一般一个项目只保存在一个项目任务文件。
如使用其它原理图和PCB图相独立的作图工具，可以在项目文件夹下区分SCH目录以及PCB目录。
华为基本法行为准则
华为作为一家全球知名的科技公司，在秉承创新共赢的理念的同时，对员工行为也有严格的要求。
为了维护公司的声誉和形象，华为制定了基本法行为准则，并要求员工严格遵守。
华为基本法行为准则包括了公司员工应遵守的一系列行为规范，其中重点关注以下方面：
首先，员工必须遵守公司的法规和内部政策，不得从事任何违法违规的行为。
其次，员工应保护公司机密信息和知识产权，并遵守公司对于保密和知识产权管理的规定。
同时，员工应遵守行业准则和商业道德，不得从事任何不诚信的商业行为。
此外，华为还要求员工尊重他人并遵守道德标准，包括不色情、不歧视、不诽谤、不辱骂等。
同时，员工应秉持诚实守信、合作共赢的精神，与合作伙伴建立良好的合作关系。
最后，华为基本法行为准则还要求员工遵守环保和社会责任，支持可持续发展并履行企业公民责任。
华为基本法行为准则的实施，为公司建立了一套完善的行为准则体系，保证了企业文化健康、发展和谐。
每一个员工都应该严格遵守基本法行为准则，发挥自己的专业和个人优势，为公司的发展做出有益的贡献。
软件开发行为规范第一版深圳市华为技术有限公司版权所有不得复制软件开发行为规范（第一版）为了把公司已经发布的软件开发过程规范有效地运作于产品开发活动中，把各种规范“逐步形成工程师的作业规范”，特制定本软件开发行为规范，以达到过程控制的目的。
与软件开发相关的所有人员，包括各级经理和工程师都必须遵守本软件开发行为规范。
对违反规范的开发行为，必须按照有关管理规定进行处罚。
本软件开发行为规范的内容包括：软件需求分析、软件项目计划、概要设计、详细设计、编码、需求管理、配置管理、软件质量保证、数据度量和分析等。
本软件开发行为规范，采用以下的术语描述：★规则:在软件开发过程中强制必须遵守的行为规范。
★ 建议:软件开发过程中必须加以考虑的行为规范。
★说明：对此规则或建议进行必要的解释。
★示例：对此规则或建议从正或反两个方面给出例子。
本软件开发过程行为规范由研究技术管理处负责解释和维护。
研究技术管理处*目录1软件需求分析5 2软件项目计划9 3概要设计11 4详细设计14 5编码18 6需求管理19 7软件配置管理21 8软件质量保证23 9数据度量和分析251软件需求分析1- 1 :软件需求分析必须在产品需求规格的基础上进行，并保证完全实现产品需求规格的定义。
1- 2 :当产品的需求规格发生变更时，必须修订软件需求规格文档。
软件需求规格的变更必须经过评审，并保存评审记录。
1- 3 :必须对软件需求规格文档进行正规检视。
1- 4 :软件需求分析过程活动结束前，必须经过评审，并保存评审记录。
1- 5 :在对软件需求规格文档的正规检视或评审时，必须检查软件需求规格文档中需求的清晰性、完备性、兼容性、一致性、正确性、可行性、易修改性、健壮性、易追溯性、易理解性、易测试性和可验证性、性能、功能、接口、数据、可维护性等内容。
说明：参考建议1-1到1-16。
1- 1 :采用以下检查表检查软件需求规格文档中需求的清晰性。
1- 2 :采用以下检查表检查软件需求规格文档中需求的完备性1- 3 :采用以下检查表检查软件需求规格文档中需求的兼容性1- 4 ：采用以下检查表检查软件需求规格文档中需求的一致性。
Panorama系统程序开辟规范之二1.匈牙利命名规则变动前缀类型a Arrayb Booleanby Bytec Char //有符号型字符cb Char Byte //无符号型字符（没多大用处）cr ColorRef //颜色参考值cx,cy Length of x,y (ShortInt) //坐标差（长度）dw Double Wordfn Functionh Handlei Integerm_ Member of a classn Short Integernp Near Pointerp Pointer lp Long Pointer×(str) s Stringsz String with Zero End //以字符结尾的字符串tm Text //文本内容w Wordx,y Coordinate //坐标2.Panorama系统的命名约定2.1 VC中变量命名时的前缀约定Array a... //例：CStringArray saTextBOOL b...UINT n...int i...short n...long l...WORD w...DWORD dw...float f...char c...char* psz...TCHAR* psz...LPCTSTR lpsz...CString str...COLORREF cr...LPLOGPALETTE lp... (包括LP开头的类型都是这样)POINT pt...CPoint pt...HANDLE h...HGLOBAL h... (包括H开头的类型都是这样)说明：1.如果是指向上述类型的指针，就在上面规范前加2.如果是指向上述类型的双重指针，就在上面规范前加3.如果是类成员变量，则在上面规范前加4.全局变量,则在上面规范前加5.在类型前加了命名约定不变;2.2 VC中变量命名时的后缀约定1.MFC类CWnd* p...Wnd 省去的地方普通为该类的用途(如果是某一个类的成员，则还应该在前加又如：CView* p...View2.3 局部变量应尽量易懂简洁，使用常见的变量，如Num,nCount,i,j,k,n,len,pos, offset,nReadNum,index,nRet,ret, string,filename暂时变量，如ltmp,ftmp,tmpStr,tempStr 。
总体原则•清晰，易于维护、易于重构•简洁，易于理解，并且易于实现• 风格统一，代码整体风格保持统一• 通用性，遵循业界通用的编程规范目录结构建议将工程按照功能模块划份子目录(可参考头文件和源文件目录。
命名LiteOS 的功能模块划分)，子目录再定义• 使用驼峰风格进行命名，此风格大小写字母混用，不同单词间通过单词首字母大写来分开，具体规则如下：大驼峰，或者带有模块函数，自定义的类型前缀的大驼峰局部变量，函数参数，宏参数，结构体成员，联合体成员全局变量宏，枚举值小驼峰带'g_'前缀的小驼峰全大写并下划线分割带'_LOS'前缀和'H'内核头文件中防止重复包含的宏变量以下划线分割AaaBbb,XXX_AaaBbb aaaBbbg_aaaBbbAAA_BBB_LOS_MODULE_H• 全局函数、全局变量、宏、类型名、枚举名的命名，应当准确描述并全局惟一后缀，中间为大写模块名，• 在能够准确表达含义的前提下，局部变量，或者结构体、联合体的成员变量，其命名应尽可能简短• LiteOS 的对外API 使用LOS_Module_Func 的方式，如果有宾语采用前置的方式，比如：1. LOS_TaskCreate2. LOS_SwtmrStart3. LOS_SemPendkernel 目录下内部模块间接口使用OsModuleFunc 的方式，比如：1. OsTaskScan2. OsSwtmrStartarch 目录需要给上层模块提供LowLevel 接口，这部份接口采用ArchModuleFunc 的方式。
其他情况可采用ModuleFunc 的方式。
排版与格式•程序块采用缩进风格编写，使用空格而不是制表符( '\t' )进行缩进，每级缩进为 4 个空格• 采用K&R 风格作为大括号换行风格，即函数左大括号另起一行放行首，并独占一行，其他左大括号尾随语句放行末，右大括号独占一行，除非后面跟着同一语句的剩余部份，如if 语句的else/elseif 或者分号，比如：1. struct MyType {//左大括号尾随语句放行末，前置 1 个空格2. ...3. };//右大括号后面紧跟分号1. int Foo (int a)2. {//函数左大括号独占一行，放行首3. if(a>0){//左大括号尾随语句放行末，前置 1 个空格4. ...5. }else {//右大括号、 "else" 、以及后续的左大括号均在同一行6. ...7. }//右大括号独占一行8. ...9. }•条件、循环语句使用大括号，比如：1. if(objectIsNotExist){ //单行条件语句也加大括号2. return CreateNewObject ();3. }1. while (condition){} //即使循环体是空，也应使用大括号1. while (condition){2. continue ;//continue 表示空逻辑，使用大括号3. }•case/default 语句相对switch 缩进一层，缩进风格如下：1. switch (var){2. case 0://缩进一层3. DoSomething1 ();//缩进一层4. break ;5. case 1 :6. DoSomething2 ();7. break ;8. default :9. break ;10. }•一行只写一条语句• 一条语句不能过长，建议不超过120 个字符，如不能缩短语句则需要分行写• 换行时将操作符留在行末，新行进行同类对齐或者缩进一层，比如：1. //假设下面第一行不满足行宽要求2. if(currentValue>MIN&& //换行后，布尔操作符放在行末3. currentValue<MAX){ //与 (&&)操作符的两个操作数同类对齐4. DoSomething ();5. ...6. }1. //假设下面的函数调用不满足行宽要求，需要换行2. ReturnType result= FunctionName (paramName1,3. paramName2,4. paramName3); //保持与上方参数对齐1. ReturnType result= VeryVeryVeryLongFunctionName (// 写入第 1 个参数后导致过长，直接换行2. paramName1,paramName2,paramName3); //换行后， 4 空格缩进一层1. //每行的参数代表一组相关性较强的数据结构，放在一行便于理解，此时可理解性优先于格式排版要求2. int result= DealWithStructLikeParams (left.x,left.y, //表示一组相关参数3. right.x,right.y); //表示此外一组相关参数• 声明定义函数时，函数的返回类型以及其他修饰符，与函数名同行• 指针类型"*" 应该靠右尾随变量或者函数名，比如：1. int*p1;//Good ：右尾随变量，和左边的类型隔了 1 个空格2. int*p2;//Bad ：左尾随类型3. int*p3;//Bad ：两边都没空格4. int*p4;//Bad ：两边都有空格当"*"与变量或者函数名之间有其他修饰符，无法尾随时，此时也不要尾随修饰符，比如：1. char *const VERSION= "V100" ;//Good ：当有 const 修饰符时， "*"两边都有空格2. int Foo (constchar *restrictp); //Good ：当有 restrict 修饰符时， "*"两边都有空格•根据上下内容的相关程度，合理安排空行，但不要使用连续 3 个或者更多空行• 编译预处理的"#"统一放在行首，无需缩进。
IT部门软件开发规章制度第一章总则第一条为规范IT部门的软件开发工作，提高软件开发的效率和质量，制定本规章制度。
第二条本规章制度适用于IT部门内所有软件开发人员。
第三条本规章制度的遵守与执行是IT部门软件开发工作的基础，违反本规章制度的行为将受到相应的处罚。
第二章开发流程第四条软件开发采用敏捷开发模式，包括需求分析、设计、编码、测试、上线等环节。
第五条在需求分析阶段，软件开发人员需与需求方充分沟通，明确需求，并撰写需求文档。
第六条在设计阶段，软件开发人员应根据需求文档进行系统设计，包括界面设计和数据库设计等。
第七条在编码阶段，软件开发人员应按照设计文档进行编码，保证代码的规范性和可读性。
第八条在测试阶段，软件开发人员应进行单元测试、集成测试和系统测试，确保软件功能正常。
第九条在上线阶段，软件开发人员应将经过测试无误的软件部署到生产环境，并进行监控和维护。
第三章编码规范第十条软件开发人员应使用统一的编码规范，包括命名规范、注释规范和代码格式规范等。
第十一条命名规范要求变量名、函数名以及类名要具有描述性，避免使用拼音、缩写或无意义的名称。
第十二条注释规范要求对关键代码进行注释，解释代码的用途和实现逻辑，提高代码的可读性和维护性。
第十三条代码格式规范要求统一使用缩进、空格和换行等，使代码整洁美观，减少错误发生的可能性。
第四章安全保障第十四条软件开发人员应严格遵守信息安全规定，保护用户和公司的敏感信息不被泄露。
第十五条软件开发人员需对软件进行漏洞扫描和安全测试，及时修复存在的安全漏洞。
第十六条软件开发人员应定期备份软件源代码和数据库，确保数据的安全性和可恢复性。
第五章知识管理第十七条软件开发人员应建立个人知识库，记录工作中遇到的问题和解决方案，并及时分享给团队成员。
第十八条软件开发人员应积极参加培训和技术交流活动，提升自身的技术水平和综合能力。
第十九条软件开发人员应关注行业的最新动态和技术趋势，保持对新技术的学习和应用。
华为编程规范华为编程规范是指在华为公司内部进行软件开发时所遵守的一套规范和标准，旨在提高代码的质量和可维护性。
下面是华为编程规范的主要内容。
一、命名规范：1. 变量和函数名应采用有意义的名称，尽量避免使用缩写或简写。
2. 变量名和函数名应使用小驼峰命名法，即首字母小写，后续单词首字母大写。
3. 常量名应使用大写字母和下划线，以增加可读性。
4. 类名应使用大驼峰命名法，即每个单词首字母大写。
5. 文件名应与其中的公共类名一致。
二、注释规范：1. 在每个函数的开头添加函数的功能说明，参数说明和返回值说明。
2. 在关键性代码部分添加注释，说明代码的逻辑。
3. 在需要修正或改进的代码部分添加TODO注释，以便后续修复。
三、代码风格：1. 缩进使用4个空格而不是Tab键。
2. 每行代码的长度不能超过80个字符。
3. 在二元操作符两边添加空格，例如 a + b。
4. 大括号应另起一行，不应与关键字在同一行。
5. 每个语句结束后都应该添加分号。
四、异常处理：1. 捕获异常时应尽量具体，不应捕获顶层异常。
2. 异常处理代码应与正常逻辑代码分离，以提高代码的可读性。
3. 异常处理代码块应添加注释，说明捕获的异常类型和处理的方法。
五、函数规范：1. 函数的长度应控制在100行以内，避免函数过长和复杂。
2. 函数的参数应尽量少，可以通过封装成结构体或类的方式来减少参数数量。
3. 函数应只完成一个功能，不应既完成数据处理又完成界面显示等功能。
六、代码复用：1. 尽量使用现有的类和框架来实现功能，避免重复造轮子。
2. 重复的代码应抽取成函数或方法来复用，提高代码的可维护性。
3. 提高代码的可移植性，使其可以在不同的平台和环境下复用。
七、测试规范：1. 添加单元测试用例，覆盖所有的代码分支，确保代码的正确性。
2. 针对不同的输入情况，测试代码的边界问题和异常情况。
3. 添加性能测试用例，确保代码在大数据量和高并发情况下的性能表现。
一、公司宗旨【追求】华为的追求是成为电子信息领域的世界级领先企业，为实现客户的价值观而持续发展。
【员工】管理有效的高素质的集体奋斗员工群体是最重要财富。
【技术】在独立自主发展核心技术基础上，开放、合作。
【精神】爱祖国、爱人民、爱事业、爱生活是我们凝聚力的源泉。
敬业、创新、团结、企业家精神是我们企业文化的精髓。
实事求是是我们行为的准则。
【文化】资源是会枯竭的，唯有文化是生生不息【利益】华为主张在顾客、员工与合作者之间结成利益共同体。
努力探索按生产要素分配的内部动力机制。
我们决不让雷锋吃亏，奉献者定当得到合理的回报。
【社会责任】华为为产业报国和科教兴国做不懈的努力，以公司的发展为所在社区作出贡献。
为伟大祖国的繁荣昌盛，为中华民族的振兴，为自己和家人的幸福而不懈努力。
二、华为人职业行为规范【尽职尽责】需要员工全身心地投入到工作中去。
1.坚持原则，一切从公司利益出发，不感情用事。
2.干一行，爱一行，专一行，脚踏实地，一丝不苟，精益求精，不断地把事情做得更好。
3.各级主管有责任根据公司发展的需要为在本职岗位上表现出色的员工提供更多的发展机会。
4.对工作目标及结果负责，积极努力去实现既定目标。
5.主动承担工作责任，出现问题时首先讲内部不讲外部，讲自己不讲别人，讲主观不讲客观，把解决问题作为首要任务。
6.敢于暴露自己工作中的问题，敢于讲真话，不捂盖子，不文过饰非。
7.苛求自己，苛求产品，不犯重复错误，把事情一次做好。
【团结协作】胜则举杯相庆，败则拼死相救。
团结合作、集体奋斗是华为文化的精髓，只有团队成功才有个人的成功。
1.小我融入大我，在团队的平台上发挥个人特长。
2.从自身做起，积极参与集体活动，努力营造团结紧张、严肃活泼的团队气氛。
3.襟怀坦白，包容他人，认同别人的长处，了解彼此的短处是团结协作的基础。
4.资源共享，积极支持和配合他人工作，积极求助于他人，同时无私地帮助他人，在互助中共同进步。
5.重视工作中的不同意见，不要把工作中的意见分歧转化为人际关系的冲突。
软件开发行为规范第一版深圳市华为技术有限公司版权所有不得复制软件开发行为规范(第一版）为了把公司已经发布的软件开发过程规范有效地运作于产品开发活动中，把各种规范“逐步形成工程师的作业规范”，特制定本软件开发行为规范，以达到过程控制的目的。
与软件开发相关的所有人员，包括各级经理和工程师都必须遵守本软件开发行为规范。
对违反规范的开发行为，必须按照有关管理规定进行处罚。
本软件开发行为规范的内容包括：软件需求分析、软件项目计划、概要设计、详细设计、编码、需求管理、配置管理、软件质量保证、数据度量和分析等。
本软件开发行为规范，采用以下的术语描述：★规则：在软件开发过程中强制必须遵守的行为规范。
★建议：软件开发过程中必须加以考虑的行为规范。
★说明：对此规则或建议进行必要的解释。
★示例：对此规则或建议从正或反两个方面给出例子。
本软件开发过程行为规范由研究技术管理处负责解释和维护。
研究技术管理处目录1 软件需求分析 52 软件项目计划93 概要设计114 详细设计145 编码186 需求管理197 软件配置管理218 软件质量保证239 数据度量和分析251 软件需求分析1-1：软件需求分析必须在产品需求规格的基础上进行，并保证完全实现产品需求规格的定义。
1-2：当产品的需求规格发生变更时，必须修订软件需求规格文档。
软件需求规格的变更必须经过评审，并保存评审记录。
1-3：必须对软件需求规格文档进行正规检视。
1-4：软件需求分析过程活动结束前，必须经过评审，并保存评审记录。
1-5：在对软件需求规格文档的正规检视或评审时，必须检查软件需求规格文档中需求的清晰性、完备性、兼容性、一致性、正确性、可行性、易修改性、健壮性、易追溯性、易理解性、易测试性和可验证性、性能、功能、接口、数据、可维护性等内容。
说明：参考建议1-1到1-16。
1-1：采用以下检查表检查软件需求规格文档中需求的清晰性。
1-2：采用以下检查表检查软件需求规格文档中需求的完备性。
1-3：采用以下检查表检查软件需求规格文档中需求的兼容性。
1-4：采用以下检查表检查软件需求规格文档中需求的一致性。
1-5：采用以下检查表检查软件需求规格文档中需求的正确性。
1-6：采用以下检查表检查软件需求规格文档中需求的可行性。
1-7：采用以下检查表检查软件需求规格文档中需求的易修改性。
1-8：采用以下检查表检查软件需求规格文档中需求的健壮性。
1-9：采用以下检查表检查软件需求规格文档中需求的易追溯性。
1-10：采用以下检查表检查软件需求规格文档中需求的易理解性。
1-11：采用以下检查表检查软件需求规格文档中需求的易测试性和可验证性。
1-12：采用以下检查表检查软件需求规格文档中的性能需求描述。
1-13：采用以下检查表检查软件需求规格文档中功能需求描述。
1-14：采用以下检查表检查软件需求规格文档中的接口需求描述。
1-15：采用以下检查表检查软件需求规格文档中的数据需求描述。
1-16：采用以下检查表检查软件需求规格文档中的可维护性需求描述。
2 软件项目计划2-1：软件项目计划必须以产品/软件的需求规格为基础。
当发生需求更改时，必须修订软件开发计划。
说明：软件项目计划必须依据需求规格进行制定。
项目计划中的工作产品和工作任务应保证能完全实现需求规格的定义。
当需求更改时，必须考虑需求更改的相关性，修订相应软件开发计划。
2-1：制定软件项目计划的活动制定，必须遵守“软件项目计划规范”。
2-2：软件经理对软件项目计划的制定和结果负责。
2-3：软件经理和相关参与软件项目计划的制定和评审的人员，在参与计划制定之前必须经过软件工程和软件项目计划制定流程的培训。
2-2：对于软件项目计划中各项工作产品和工作任务，必须进行规模和工作量的软件估计，并在软件项目计划文档中记录估计的方法和估计数据。
说明：参考建议2-4到2-8。
2-4：可以使用PERT统计估计、专家判定平均法、经验类比估计、公式计算等方法，或以上方法的组合，进行软件估计。
示例：PERT统计估计和经验类比估计的结合PERT统计估计值＝ (最大估计＋4×期望估计＋最小估计〕/ 6估计记录如下：期望估计值是根据XX版本的话统模块设计的数据获得。
2-5：对某项工作产品和任务的软件，同时采用两种或以上的方法进行估计，以避免一种方法的偏差。
2-6：尽量采用历史经验数据进行软件估计。
2-7：参照“软件估计指导书”进行软件估计。
2-8：软件估计对应项目的任务分解结构进行。
说明：软件估计对于项目的任务分解结构对应得越清晰、越细致，相应的估计越准确。
2-9：在“软件项目计划”中必须包括项目管理活动的计划。
2-10：在“软件项目计划”中包括软件重用计划。
包括重用软件部件的计划和开发可重用软件部件的计划。
2-11：在“软件项目计划”包括人员的培训计划。
说明：项目人员计划包括需要的人员类型、数量和技术等级的要求，相关人员的开始工作时间、工作周期、接受培训的计划等。
2-12：对软件项目进行风险分析与评估。
说明：可能存在的风险领域含：需求的不明确和变更、外部的限制与对外的依赖、人力资源的到位情况、人力资源的技术等级满足要求状况、技术问题等。
对风险的分析与评估实践包括：从已知的情况推导出潜在风险；对风险进行分析，得出：潜在风险可能引发的问题的影响、潜在风险发生的可能性大小、风险发生的时间段等；排列风险的重点次序；对风险记录成文件（属于软件项目计划中的一部分）；风险经受风险影响人审核，并取得他的同意；根据需要，在开发过程中对风险文档进行维护和修订。
2-3：对应工作任务，制定项目的文档计划。
2-4：软件项目计划中应该包括正规检视活动计划、软件质量保证计划、软件配置管理计划。
软件质量保证计划和软件配置管理计划可以和软件项目计划在同一份文档中，也可以分开为三份文档。
说明：参考建议2-13。
2-13:软件质量保证计划和软件配置管理计划作为独立的计划文档。
2-14：软件项目计划必须是整个项目开发过程的计划，包括测试。
2-15：测试经理对照整个开发计划建立软件验证与确认计划。
软件验证与确认计划可作为独立的计划文档。
2-5：必须对项目工作进行分解，确定项目的工作任务，任务的责任人、资源要求、时间要求、项目的进度。
2-6：必须分析任务之间的依赖性，确定并明确标识项目的关键路径。
2-7：“软件项目计划”必须按照文档模板的要求编写。
项目组可根据项目的实际情况，对文档模板中的内容进行裁减。
项目组对文档模板内容的裁减必须得到上级管理部门（包括产品计划处、软件工程组SEPG）的审核批准。
2-8：软件项目计划必须经过评审。
说明：参考建议2-16。
2-16：软件项目计划的评审采用以下检查表。
2-17：参加“软件项目计划”评审的人员，除软件经理和项目组人员外，必须有产品经理、上级管理部门（包括软件工程组SEPG）、SQA人员。
2-18：“软件项目计划”通过评审后，软件经理组织相关人员对任务进行承诺，签定工作任务书。
2-9：必须对“软件项目计划”进行配置管理，“软件项目计划”的更改必须经过评审。
2-10：在开发活动中，必须按照项目跟踪与监控计划和体制，对照“软件项目计划”，跟踪项目开发的实际结果和性能。
2-11：当实际结果和“软件项目计划”发生偏离时，必须进行分析，根据分析结果标明纠正措施。
必要的情况下，要及时修订“软件项目计划”。
2-12：在软件项目跟踪监控活动中，必须定期进行总结和评审，撰写开发状态报告。
2-19：根据项目的特点，报告的周期可以为周、双周、月。
2-13：在软件开发各里程碑阶段结束前，必须进行阶段评审，对软件项目进行重估计，必要的情况下修订“软件项目计划”。
2-20：必须提供相应资源，包括工具和人员等，进行软件项目计划和项目跟踪监控活动。
2-14：在软件项目计划和项目跟踪监控过程活动中，必须进行数据度量和分析。
说明：参见“9. 数据度量和分析”。
3 概要设计3-1：概要设计要以软件需求规格为基础，必须保证需要实现的需求规格已经被设计。
3-2：当需求规格发生变更时，必须修订相关概要设计文档。
3-3：在概要设计文档或需求管理文档中，必须记录、验证需求和概要设计的跟踪关系。
说明：需求和概要设计的跟踪关系可参考建议3-1。
3-1：采用需求、子系统、模块的跟踪矩阵表记录需求和概要设计的跟踪关系。
3-4：必须保证概要设计文档和代码的一致性。
当发生设计更改时，必须修订相应设计文档。
3-5：必须对概要设计文档进行正规检视。
3-6：概要设计过程结束前，必须通过评审，并保存评审记录。
3-7：设计更改必须经过相关评审，并保存评审记录。
3-8：对概要设计文档的正规检视或评审，必须检查概要设计文档的清晰性、完备性、规范性、一致性、正确性、数据、功能性、接口、详细程度、可维护性、性能、可靠性、可测试性、可追溯性。
说明：参考建议3-2。
3-2：采用以下检查表检查概要设计文档的清晰性。
3-3：采用以下检查表检查概要设计文档的完备性。
3-4：采用以下检查表检查概要设计文档的规范性。
3-5：采用以下检查表检查概要设计文档的一致性。
3-6：采用以下检查表检查概要设计文档的正确性。
3-7：采用以下检查表检查概要设计文档的数据描述。
3-8：采用以下检查表检查概要设计文档的功能性要求。
3-9：采用以下检查表检查设计的接口描述。
3-10：采用以下检查表检查设计的详细程度。
3-11：采用以下检查表检查设计的可维护性。
3-12：采用以下检查表检查设计的性能。
3-13：采用以下检查表检查设计的可靠性。
3-14：采用以下检查表检查设计的可测试性。
3-15：采用以下检查表检查设计的可追溯性。
4 详细设计4-1：详细设计要以软件需求规格和概要设计为基础，必须保证需要实现的需求规格已经被设计，必须保证概要设计定义的所有模块已经被详细设计。
4-2：当需求规格或概要设计发生变更时，必须修订相关详细设计文档。
4-3：在详细设计文档或需求管理文档中，必须记录、验证需求、概要设计、详细设计的跟踪关系。
说明：需求、概要设计、详细设计的跟踪关系可参考建议4-1。
4-1：采用需求、子系统、模块、函数的跟踪矩阵表记录需求、概要设计、详细设计的跟踪关系。
4-4：必须保证详细设计文档和代码的一致性。
当发生设计更改时，必须修订相应设计文档。
4-5：必须对重要的详细设计文档进行正规检视。
说明：参考建议4-2。
4-2：根据模块的复杂度、规模和在软件系统中的重要程度，选择重要的详细设计文档进行正规检视。
在产品中，进行正规检视的详细设计文档比例要达到60%。
4-6：详细设计过程结束前，必须通过评审，并保存评审记录。
4-7：设计更改必须经过相关评审，并保存评审记录。
4-8：对详细设计文档的正规检视或评审，必须检查详细设计文档的清晰性、完备性、规范性、一致性、正确性、数据、功能性、接口、详细程度、可维护性、性能、可靠性、可测试性、可追溯性。
