软件开发规范与开发流程实施

软件开发标准

&

开发流程实施中山市森创公司软件开发什么是软件工程完成特定目的、符合用户特定需求的软件所需的组织结构和过程、标准的集合软件工程的实施需要周密的部署，合理的规章制度，符合工程的路线〔软件过程〕，良好的工程管理和人员安排。相关流程软件管理特点软件生命周期过程确定需求开发规划需求分析概要设计详细设计编码与调试测试软件集成、联调内部确认复制、交付、安装试运行、用户验收运行、维护退役软件管理配置与变更管理环境、工具和技术有关软件的法规和标准周密筹划以保证软件管理特点软件产品的特点软件产品的质量，完全取决于其设计和开发水平软件需求的模糊性、变化性使软件产品难以成熟任何一个软件产品，或多或少总会存在一些故障(BUG)软件人员广泛存在的不标准的开发习惯使开发过程难以管理软件质量指标难以量化软件测试理论和技术尚未解决软件产品正确性的验证问题软件产品质量特性：满足需求能力的一系列特性总和功能、可靠性、易用性、效率、维护性、可移植性软件管理必须在市场(用户)需求和软件成熟性之间进行权衡软件生命周期过程确定需求开发规划需求分析概要设计详细设计编码与调试测试软件集成、联调内部确认复制、交付、安装试运行、用户验收运行、维护退役确定需求确定外部用户需求上级下达的软件开发课题本单位根据市场需要确定的开发课题用户合同要求的软件开发任务输出可行性分析报告技术、经济、社会可行性，风险对策合同及评审记录产品要求得到规定和满足单位有能力满足规定的要求开发规划确定开发目标确定工程开发的技术路线(开发的出发基线、对现有产品的复用、委托开发等)确定应遵循的标准、法律和法规选任开发工程经理划分开发阶段确定各阶段的输入和输出文件确定质量控制点(评审点、验证点和确认点)及其实施的责任人、实施方式等设计工程开发进度确定开发人员并分配职责提出开发所需资源(软件、硬件开发环境及工具软件、设备、资金等)要求并予以落实制定配置管理方案和质量保证方案开发规划(续)输出筹划报告开发工程实施方案配置管理方案质量保证方案等需求分析确保工程的开发符合用户的需求(可测试性)确定设计输入任务委托书/招标书前期对用户的需求调研资料可行性分析报告/投标书合同等编制内部需求规格(说明)书需求变更控制需求的层次业务需求、用户需求和功能需求概要设计确保产品的总体结构和模块间的关系与用户需求的一致性内容总体方案设计逻辑框图接口及通讯协议选用现有产品软件的选用边界(约束)条件的设计运行环境设计等输出概要设计说明书详细设计详细设计说明书与概要设计说明书是否相一致内容原型设计〔可选〕算法设计数据格式设计实现流程设计人机界面设计测试用例设计操作设计等输出详细设计说明书软件组装方案测试方案及测试用例安装手册(初稿)使用说明书(初稿)产品标准(初稿)编码与调试内容编写程序代码：源代码→目标代码→可执行代码此阶段还包括局部软件模块的局部测试、集成与联调根据待开发软件的规模、控制点及人员安排，可细分为多个小阶段输出软件(源代码、目标代码、可执行代码及相关数据文件)文档(帮助文件等)遵循?编码标准?，保证编码风格的一致性，易读性；增强软件源码的可维护性测试按测试发生的顺序划分模块测试：是对单个软件模块的测试单元测试：是对各个软件功能单元的测试组装测试：是对各软件单元之间的互联测试集成测试：是对硬件装置、设备和软件的参加性测试系统测试：工程组所在部门组织的对完成集成的系统的测试(是否满足产品规格要)压力测试：是对软件的整体经受超大访问量压力下能否保证平安、正确运行的测试确认测试：单位质量控制部门进行的测试(是否满足产品规格要求)验收测试：在现场安装、调试结束并经试运行后，与顾客一起，就满足合同情况进行的测试(是否满足合同要求)ISO9001

&

CMMISO9001&CMM什么是ISO9001？ISO9001是ISO9000族标准所包括的一组质量管理体系核心标准之一。ISO9000族标准是国际标准化组织〔ISO〕在1994年提出的概念，是指“由ISO/TC176〔国际标准化组织质量管理和质量保证技术委员会〕制定的国际标准。ISO9001质量管理体系不是专门针对软件开发的，还可以实施到其它行业比方生产、教育等。ISO9001质量管理体系在软件开发中，对软件开发过程进行严格的质量控制。这个过程需要由企业本身和ISO审查小组联合进行质量控制，分为内审和外审。内审：由企业内部成立一个专门的质量控制小组〔需经过培训〕，参与到软件开发的整个流程〔从立项到产品交付〕的文档审查和质量控制中。外审：由ISO审查小组派专员到企业中，对企业的软件开发过程进行审查〔只要审核各个流程生成的相关文档是否齐备，符合标准等。还有能软、硬件设施和人员也有一定的要求〕。ISO审查专员需要具备ISO9000外审员资格证书。ISO9001&CMM什么是CMM？

软件能力成熟度模型(CapabilityMaturityModelForSoftware,简称SW-CMM/CMMI),是由美国卡内基梅隆大学软件工程研究所(CMUSEI)研究出的一种用于评价软件承包商能力并帮助改善软件质量的方法，其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。CapabilityMaturityModel

软件能力成熟度模型迄今为止学术界和工业界公认的有关软件工程和管理实践的最好的评价模型。为评估软件组织的生产能力提供了标准。为提高软件组织的生产过程指明了方向。CMM五级软件开发模型软件开发模型统一软件开发过程

&敏捷开发统一软件开发过程&敏捷开发什么是统一软件开发过程?RUP〔RationalUnifiedProcess，统一软件开发过程，统一软件过程)是一个面向对象且基于网络的程序开发方法论。根据Rational(RationalRose和统一建模语言的开发者)的说法，好似一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针，模版以及事例支持。RUP和类似的产品--例如面向对象的软件过程〔OOSP〕，以及OPENProcess都是理解性的软件工程工具--把开发中面向过程的方面〔例如定义的阶段，技术和实践〕和其他开发的组件〔例如文档，模型，手册以及代码等等〕整合在一个统一的框架内。统一软件开发过程用例驱动用例:能向用户提供有价值的系统的某种功能以架构为中心软件架构：系统的最重要的静态和动态特征迭代和增量式迭代：工作流程的重复、每次的活动都以上次的活动为根底用例驱动用户所希望和需要的是什么系统能为每个用户提供什么功能用例所描述和代表的是用户与系统交互的一个过程，而这个过程满足了用户的某些需求所强调的是系统的功能以架构为中心刻画了系统的整体设计，忽略了细节设计，刻画最重要的局部。什么是最重要的呢？依赖于判断。判断的依据是经验。构架的设计价值取决于执行该任务的人的素质受用户需求〔用户可能会增加那方面的需求〕、软件应用平台〔计算机硬件、操作系统、数据库、网络等〕、实施问题、遗留系统集成等的影响用例和架构用例是系统的功能和外衣架构是系统的内在形式两方面必须并行进化架构只考虑核心功能(5-10%)架构设计原那么：先考虑与用例无关的不会变动的方面考虑考虑最重要的功能需求子集迭代和增量式控制迭代过程，划分每次迭代的目标迭代原那么：架构上先实现最粗略的局部功能上先实现最重要的每次迭代尽可能的划分的细，迭代数量不能太少每次迭代要有标准的检查机制增量式每次迭代增加一局部设计和实现统一软件开发过程&敏捷开发什么是敏捷开发？2001年，为了解决许多公司的软件团队陷入不断增长的过程泥潭，一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原那么，他们称自己为敏捷联盟。敏捷开发过程的方法很多，主要有：SCRUM，Crystal,特征驱动软件开发〔FeatureDrivenDevelopment，简称FDD〕，自适应软件开发(AdaptiveSoftwareDevelopment，简称ASD)，以及最重要的极限编程(eXtremeProgramming,简称XP)。极限编程(XP)是于1998年由Smalltalk社群中的大师级人物KentBeck首先倡导的。敏捷开发快速适应系统需求的变化提高软件生产率突出企业自身特点，表达企业核心能力支持动态联盟和虚拟组织面向业务目标持续改进和重组敏捷软件开发宣言个体和交互胜过过程和工具可以工作的软件胜过面面俱到的文档客户合作胜过合同谈判响应变化胜过遵循方案敏捷开发的特征轻量级的开发过程基于时间JustEnough并行基于组件的软件工程敏捷开发过程软件的需求是难以预期的，开发方法必需适应变化的需求，在快速的迭代中不断改进小组成员并不完全按照完整的方法进行开发，而根据具体问题和情况，灵活地去除非增值活动仅仅执行一些必须的活动，使用必须的规那么，编写必须的文档人的因素被放在第一适合互联网时代的开发要求主要敏捷开发方法eXtremeProgramming(XP)SCRUMDSDMAdaptiveSoftwareDevelopment(ASD)FeatureDrivenDevelopment(FDD)CrystalFamilyRationalRUP&UML软件开发标准软件开发标准开发标准的作用1)开发标准作用于团队开发内部，保证不同的开发人员在工作环境设定，代码开发标准以及日常开发的行为能够到达共通的要求。2)开发标准用于开发的各个阶段，保证开发中的各个问题能够按照开发制定的标准进行处理〔比方：代码管理，版本冲突，代码命名标准等等〕。3)开发标准作为最终开发产品代码的检测标准,通过对最终产品代码的再次检测，来保证代码的标准性，可维护性。开发标准作为开发中的检测标准，来约束开发人员的开发行为，到达在团队内部提高开发质量和减少开发本钱的作用。软件开发标准开发标准的要求1)制定开发时要求对于要求的内容必须语义清晰，确保所制定的内容不会有歧义发生。2)对于开发中说明性的内容，以图片说明为主，减少文字性的描述。3)对于开发标准防止在工程开发后发生对代码命名，代码逻辑分层等局部内容的变更。4)如果开发标准发生变更，确保工程团队内部所有的人员都按照最新的开发标准进行开发。5)对于开发标准也要求进行版本管理。开发标准的内容〔一〕1)开发平台的约定a)开发操作系统环境和最总用户使用环境〔包含ServicePack版本号〕b)开发工具版本c)数据库类型已经版本d)网络状态e)版本控制工具f)开发使用硬件环境和组成g)开发标准的执行问题开发标准的内容〔二〕2)工作方式的约定a)开始工作前的行为〔每天开始工作先CheckOut代码〕b)工作结束后的行为〔每天结束后需要CheckIn全部代码〕c)版本控制行为〔代码CheckIn的要求和发生冲突的解决方法〕d)文件保存要求〔新增代码文件和备份文件的处理〕开发标准的内容〔三〕3)代码书写约定a)代码的命名规那么b)代码的注释要求c)代码的修改履历要求d)代码的文件保存要求〔一个类保存在一个文件中等〕e)代码的外观要求〔代码的对齐，换行要求〕f)数据库代码的书写要求开发标准的内容〔四〕4)程序的结构约定

a)通用代码的处理方式

b)接口的处理方式

c)代码的内部的逻辑划分要求

d)程序的分层结构要求

e)程序的异常处理要求开发标准的内容〔五〕5)辅助工具的使用约定

a)版本控制工具使用说明

b)代码生成工具的使用说明

c)单元测试工具的使用说明

d)Bug管理工具的使用说明开发标准的内容〔六〕6)其他约定a)单元测试方法约定b)版本控制约定c)方案管理约定d)测试数据的约定开发标准的执行问题1)制定问题a)鼓励全部的工程开发人员都参与标准的制定b)制定标准是需要考虑代码的维护性和实际开发的便利性2)执行问题a)依照开发标准对于代码进行检测，对于存在问题要求修正。b)通过团队内部人员交叉检测的方式来执行开发标准版本控制工具的使用使用VSS〔VisualSourceSafe〕作为版本控制工具。工程配置的根本目录结构根据具体的工程设置配置库的根本目录结构，并进行根本的解释，一般可以包含以下的一级目录及二级目录：01工程工作库01准备阶段02需求分析阶段03系统设计阶段04系统实现阶段--源代码安放在此目录05系统测试阶段06运行推广阶段07系统维护阶段02工程管理库01质量保证02工程管理03配置管理04测试管理03工程共享库01工程模版02工程标准03工程制度04共享资料04工程基线库01方案基线02需求基线03设计基线04产品基线05个人工作库下设每个工程组成员的目录06其他BUG数据库--MantisBUG数据库〔Bug管理工具〕目前暂定为使用Mantis可通过://192.168.1.90:8081/Mantis进行试用。用户名：demo密码：demoBUG数据库--Mantis进入查看问题列表显示存在的问题数报告一个新的问题更新个人资料Mantis—我的视图Mantis—提交问题问题的分类，将问题归类起来，方便按分类统计问题问题的出现频率：总是/有时/随机/没有试验/无法重视/不适用问题的严重性：新功能/小细节/文字/小调整/很严重/崩溃/宕机问题的优先级：无/低/中/高/加急/特急将问题分派给谁，由谁来负责修改。对于测试员不清楚由谁负责，可分派给工程经理，由工程经理来重新分派。Mantis—统计报表软件开发流程实施现存问题实现的功能不是最初的设计目标,既产品规格和产品开发的一致性团队成员之间缺乏有效沟通产品规格更改维护产品进度无法控制测试方案文档管理解决方法软件开发过程管理资源管理,包括管理时间,管理本钱,管理人员产品管理,管理功能,实现,质量实施步骤团队建立-一个高效的团队具有如下特征目标一致,信念明确积极有效沟通,不要假设别人已经知道主动做事,主动促进流程改进,主动回复别人EMAIL等,主动共享信息通过Process〔流程〕使成员各司其职,每件事情必须有负责人数字化管理实现方式:流程+工具+文档+数字实施考虑软件流程改进实施前提条件-作为软件企业的ERP系统,改变必然涉及每一个人的日常工作和思维方式,必须有强有力的领导支持和自适应的能力.企业已经建立了有效的邮件管理机制和信息共享机制(通过内部站点共享知识库,资源等).潜意识的有效沟通-使每一次需求更改都被所有的团队成员知道高效率协作,没有权利而是依靠权威和知识领先性的管理方法,结果是高创造性积极工作,发表意见,改进流程实施误区不考虑企业自身的情况,盲目实施流程过度强调工具的重要性:如过度强调自动化测试工具而忽略了测试流程改进本质-注重沟通强调沟通,更注重实用性团队成员之间的相互牵制,三权分立;程序经理〔PM〕开发组〔DevelopTeam〕测试组〔TestTeam〕沟通不会自动发生日常会议里程碑总结(PostMotem)每日,每周汇报Bug检讨会议〔BugTriageMeeting〕代码审核〔CodeReview〕流程改进本质-使软件开发可控制使软件过程开发成为一个可控制的过程数字化管理:基于数字的软件开发度量树立时间方案的权威性,有效控制时间软件产品有清晰的标准:功能规格书(FunctionalSpecification)作为全组的标准,必须具有权威性基于功能的进度方案和多个检查点保证所有的功能实现符合功能规格书流程改进本质-持续主动调整必须专门的人员监测整个软件开发流程,并加以调整.将尽可能多的流程书面化.流程的不断变化和不同时期角色的工作重点调整工程初始化(一)软件企业需要一个能够满足缺陷跟踪和管理的工具,同时能够为决策提供支持.市场调查(市场人员),并给出产品需求书产品前景目标用户产品包和构件平台支持,硬件和软件环境语言支持功能要求管理层决定实施该工程,并决定工程经理,测试小组长,开发小组长人选管理层决定工程会议的时间工程初始化(二)工程发动大会听众:所有可得到的人力资源主题宣布工程开始工程前景陈述团队组织人力资源获得:招聘+培训工程发布时间工作准那么-明确准那么,积极工作〔一〕工程经理的工作进度监控,树立各种规格和进度表的权威性沟通中心,对内确保每一个理解产品的前景,功能和对外确保管理层的支持和满足顾客需求工程经理一般是整个团队的凝聚力所在工程经理的主要工作以写规格,开会和查看Email,进度监控,查看BUG数据库和沟通为主开发小组长的工作通过CodeReview代码审核提供高质量代码制定合理的时间方案技术选型,代码重利用从而到达按时完成代码总体构架设计和通用程序设计团队成员沟通工作准那么-明确准那么,积极工作〔二〕测试小组长的工作测试环境的建立测试策略制订测试方法和工具的选用测试案例的维护发布测试报告工作准那么-明确准那么,积极工作〔三〕工程管理〔M0〕目的设定项目目标和计划开始完成产品前景分析，需求分析，系统设计结束开始编码项目经理责任1.完成产品规格书;2.确定产品功能优先级;3.确定项目日程表4.处理外部部件和其它组关系;测试计划检验开发组责任开发组日程表;代码和构架设计;决定各个功能在哪个里程碑完成;规格书检验;测试计划检验测试组责任规格书检验;初始化缺陷数据库;移植前一个版本中的延迟的缺陷数据;添加支持部报告的缺陷;用户培训规格书检验(易用性,完整性和与其它产品的关系),并反馈给项目经理;提供文档资料计划;日程安排管理层评估上个项目,并改进流程;评估从项目中得到的数据(如缺陷数据分析,工作量统计,缺陷质量);定义不同团队之间的合作方式;同意项目计划;其它工作人员培训,熟练掌握各种工具.建立源代码效劳器,培训工程组成员使用版本控制工具.确定各团队工作目录确定常规会议,如周工程状态会议新员工工作手册,使新的员工能够非常清楚的知道各个效劳器和环境安装,及工作流程建立测试效劳器和发布效劳器测试团队建立BUG数据库效劳器建立团队工作信息发布站点,发布团队新闻,共享文档资源,工程组员联系方式,任务列表等.文档模板-功能规格书人力资源+FeatureTeam(功能团队)前景描述平台要求语言支持(本地化和全球化)出错处理(日志,警告,信息)和最终返回错误信息用户场景(UserScenarios)功能细分和说明安装程序快捷键要求性能目标用户培训文档和进度方案进度方案(MicrosoftProject)UI设计文档文档模板-实现规格书实现文档是一个文档集,包括数据字典资源管理开发环境,技术选型,程序构架和设计模式代码重用模块划分出错处理多语言支持性能考虑数据库设计公用接口设计文档模板-测试方案(一)测试环境描述,包括效劳器,安装程序描述人力资源划分测试流程及不同阶段的测试重点功能完备性测试测试目标,范围和质量标准测试区域划分易用性测试性能测试可靠性测试平台测试(使用矩阵)恢复测试回归测试 缺陷跟踪工具文档模板-测试方案(二)测试策略描述,频率和所有者测试案例开发和维护,制订测试案例覆盖标准自动化工具开发,决定何时进行自动化工具开发存在大量的API和大量的测试案例测试案例只需要结果〞通过〞或〞不通过〞,不需要用户的干预有大量的回归测试案例雇开发人员写自动化工具比雇多个测试员廉价测试脚本开发测试工具源代码分析工具测试进度如何实现成功的进度方案进度方案由整个开发团队来制定进度方案而不是工程经理单独制定事情无论大小,全部列入方案或算进缓冲保证进度方案的权威性.可以将进度方案贴在作战会议或工作房间的墙壁上工程经理必须非常清楚最重要的事情并推动执行.尤其是在不同的里程碑切换时.并将这一信息传达给全组.在制订方案时,必须考虑到会议,假期,汇报工作,单元测试,病假,解决缺陷和不可预料的事件.缓冲一般为30%~50%.在固定发布日期条件下,尤其应该增长缓冲.如何实现成功的进度控制监控和度量每天组员提交工程进度日报每周工程经理提交工程周报,开发小组长和测试小组长分别提交工程周报对当前工程状态进行总结,这些报表的听众必须是所有团队成员,包括管理人员.周报的格式和日报格式相同 在周报中安排除了日常工作以外的其它必须检查的事宜.这可以补充进度方案的缺乏每周召开团队会议,总结工程当前状态.工程管理〔M1〕目的开发产品,保证代码质量并降低BUG数量开始编码开始结束测试团队认为编码按时符合规格书规范完成项目经理责任管理产品规格书,管理功能组工作状况,保持全组工作重点,推动工作进度开发组责任设计,记录和编码;单元测试,每日构建;解决问题;保证按时完成;测试组责任设计,记录测试规范;写自动化测试编码;在正式提交的代码中进行可接受测试;在里程碑时运行所有的测试案例;报告和关闭缺陷;给出产品质量和功能完成性评估报告;认证功能完成;检验用户文档用户培训书写用户教育文档;基于用户任务来评估功能的完成;用户辅助工具;用户教育文档测试计划工作流程(一)开发组员检查BUG数据库和电子邮件.如果发现自己的BUG数量高于给定值,那么停止开发,更改BUG.工程经理和各组长检查BUG数据库和电子邮件.指派BUG给某一个组员.如果可争议BUG太多,召开BUG检讨会议,讨论BUG的优先级.每天的发布版本中需要包含说明文件(本版本更正BUG,实现功能,改变的文件),如果是API测试应包含类库文档工作流程(二)工程组员每天早上从源代码效劳器下载代码,更新其它程序员的改变。工程组员编辑自己的程序,实现程序功能。工程组员编译自己的本地源代码拷贝并进行单元测试,如无错误,交给测试组员测试.如果没有错误,提交到源代码效劳器.通过这种方法保证源代码效劳器中的程序始终是可运行的.如果本次CHECKIN完成了某一个功能,提交到测试组测试,证明此功能已完成并可测试工程组员提交工程日报.工作流程(三)测试组指定专门的可接受测试人员,并给出可接受的标准.8:30-9:00,指定的测试人员每天早上运行可接受测试,如果成功发EMAIL给全组.其它测试人员开始进行功能测试.功能测试仅测试那些已经提交测试的功能.测试组发现BUG,并登记在BUG数据库中.测试组进行其它测试,如性能测试,本地测试和平台测试.测试频率和目标在测试方案中制定。测试组根据测试方案开发测试用例,编写自动化工具和测试脚本.测试组提交测试日报使用源代码控制工具放入源文件,文档资料和所有频繁改动的资料不要放入二进制代码,包括动态库DLL和可执行文件EXE只修改需要改动的代码(SDEDIT)每次CheckIn时,填写变化列表。每次CheckIn之前,保证本地编译通过,并通过代码审核建立每日发布的源代码标签,便于回滚到某一个特定的编译生成时的源代码.管理你的BUG数据库建立并备份你的BUG数据库定义BUG管理流程清楚地定义BUG类别和属性建立起BUG的权威性,如果一个BUG可以方便地被重现,该BUG必须被修复.设定BUG数上限开发组员不能选择〞不做修改〞和〞稍后处理〞作为一个BUG的解决方案监测BUG数据库,利用数字标准作为衡量标准,并使全组人员知道这些数字.软件开发质量(一)前提条件,在实施的过程中和过程后收集大量数据工程开发过程中的数据收集每日,每周登记的缺陷和解决的缺陷(按照严重性统计)跟踪每日已激活缺陷和已解决缺陷数目修改缺陷数目;已解决的缺陷数目(除去重复和不可重复缺陷)跟踪缺陷重新激活次数缺陷的发现途径:随即测试,测试案例开发,可接受性测试解决缺陷的平均时间关闭缺陷的平均时间最老的缺陷软件开发质量(二)总结过程中的数据收集不同等级的缺陷百分比方案的测试工作量实际的测试工作量“SHOWSTOPPER〞缺陷的产生原因:缺乏测试案例由于修改其它缺陷引起的新缺陷,测试区域划分导致没有进行测试,回归测试配置测试,不是所有的机器上都可以重现错误标准不完整最后加的功能如何作CodeReview(代码审核)标志代码错误,如通过编译检查的代码拼写错误,违反编码标准,硬编码(hardcode)字符串和配置;标明算法错误,如选择错误的算法或没考虑边界情况.标志潜在的回归式错误标志可改进的地方教育开发人员CodeReview的步骤代码应该在多个平台上编译成功代码首先必须被开发人员测试过.使用DEBUGGER单步执行,或添加跟踪语句.代码必须被提交给代码审核者,使用Windiff工具比较不同代码审核的结果应该是接受,有条件的接受和拒绝代码审核的结果必须在下次审核之前更正,并提交.代码审核CheckList是否符合编码标准是否有HARDCODE字符串是否使用数字来定义数组大小,而不是使用常量或宏是否自己写代码而不使用类库开发人员是否误解了类库的参数开发者是否假定某一平台来开发程序,从而在其它平台上不能运行是否去除了