精华内容
下载资源
问答
  •  SMT车间温湿度管理规范  一)目的  a.确保各类电子材料使用在符合MSD组件管理的环境;  b.确保锡膏等材料使用在可稳定发挥其物理化学特性的环境;c.确保各类电子材料使用在符合ESD防护标准的环境;  ...

    SMT概念

      SMT是表面组装技术(表面贴装技术)(SurfaceMountTechnology的缩写),称为表面贴装或表面安装技术。是目前电子组装行业里最流行的一种技术和工艺。

      它是一种将无引脚或短引线表面组装元器件(简称SMC/SMD,中文称片状元器件)安装在印制电路板(PrintedCircuitBoard,PCB)的表面或其它基板的表面上,通过回流焊或浸焊等方法加以焊接组装的电路装连技术。

    一文看懂SMT车间生产环境要求及管理规范

      SMT车间生产环境要求

      有很多初次使用SMT设备,对于SMT生产设备工作环境的要求不是很了解,借此深圳智驰科技采集了一些环境要求,供大家参考,首先告诉大家的是--SMT生产设备是高精度的机电一体化设备,设备和工艺材料对环境的清洁度、湿度、温度都有一定的要求,为了保证设备正常运行和组装质量,对工作环境有以下要求:

      1、厂房承重能力、振动、噪音要求厂房地面的承载能力应大于8KN/m2

      振动应控制在70dB以内,最大值不超过80dB噪音应控制在70dBA以内。

      2、电源

      一般要求单相AC220(220±10%,0/60Hz),三相AC380(380±10%,50/60Hz),电源的功率要大于功耗的一倍以上。

      3、气源

      根据设备的要求配置气源的压力,可以利用工厂的气源,也可以单独配置无油压缩空气机,一般压力大于7kg/cm2。要求清洁、干燥的净化空气,因此需要对压缩空气进行去油、去尘、去水处理。用不锈钢或耐压塑料管做空气管道。

      4、排风

      回流焊和波峰焊设备需配置排风机。对于全热风炉,排风管道的最低流量值为500立方英尺/分钟(14.15m3/min)

      5、照明

      厂房内理想的照明度为800~1200LUX,至少不低于300LUX,低照明度时,在检验、返修、测量等工作区域安装局部照明。

      6、工作环境

      厂房内保持清洁卫生、无尘土、无腐蚀性气体。生产车间应有清洁度控制,清洁度控制在:50万级。

      生产车间的环境温度以23±3℃为最佳,一般为17~28℃,相对湿度为45%~70%RH.根据车间大小设置合适的温湿度计,进行定时监控,并配有调节温湿度的设施。

    一文看懂SMT车间生产环境要求及管理规范

      SMT车间温湿度管理规范

      一)目的

      a.确保各类电子材料使用在符合MSD组件管理的环境;

      b.确保锡膏等材料使用在可稳定发挥其物理化学特性的环境;c.确保各类电子材料使用在符合ESD防护标准的环境;

      二)范围

      广西三诺数字PCBA部SMT车间电子仓

      三)权责

      3.1日常记录及核实:电子仓和SMT车间

      3.2稽核温湿度环境:品保部

      3.3温湿度环境维护:机电部

      四)内容

      4.1规定:

      电子仓/SMT车间温度在22~28℃,湿度在30%RH~70%RH

      4.2管理:

      4.2.1SMT:

      4.2.1温湿度测量计安放于SMTline1s1,line3s2两处,每天上午8点,下午13点做登记,记录于《《温湿度记录稽核表》》

      4.2.1.2SMT开线前2小时,设施管理部需将环境恢复到4.1之要求;

      4.2.1.3温湿度异常时,填写《《温湿度异常反馈表》》通知设施管理部相关人员立即改善;

      4.2.1电子仓:

      4.2.2.1温湿度测量计安放于电子仓,每班做登记,记录于《《温湿度记录表》》

      4.2.2.2温湿度异常时,立即通知设施管理部相关人员改善;

      五)应用表单

      《《温湿度记录表》》

      《《温湿度异常反馈表》》

    一文看懂SMT车间生产环境要求及管理规范

      SMT车间规章制度

      1.进入SMT车间必须穿好静电衣,静电鞋,进入车间必须从风淋门进入,走出车间时需随手将门反锁

      2.当班班组在下班,交班前将车间的5S做好

      3.接班班组人员把料对好,品质人员及操作人员写好检查记录

      4.锡膏、锡线等生产耗材必须妥善保管,不得随意乱丢、乱放,不得将焊锡丝剪断乱放

      5.在维修过程中产生的废锡渣,不得倒入垃圾箱,应放入指定的废锡存放点。

      6.不得将PCB板随意乱放,下班时应清理自己的工作台面。当日值日生打扫车间和设备卫生并将所有的门窗、电源关闭(放假)。否则,若发生失窃等意外事故,将追究值日生及车间主管的责任。

      7.在工作及管理活动中严禁有不听劝告吵架闹矛盾欺负员工的现象

      8.按时上下班(员工参加早会需提前5分钟到岗),不迟到,不早退,不旷工(如遇赶货,上下班时间按照管理人员的安排执行),有事要请假,依考勤管理制度处理

      9.工作时间内,除组长以上管理人员因工作关系在车间走动,其他人员不得无事擅自离开工作岗位相互窜岗

      10.上班后任何人不得因私事而提出离岗,如有私事必须离岗者,须事先请假批准方可离岗(带上离岗证),如未经批准擅自离岗者每次处罚10元

      11.禁止在车间聊天、嘻戏打闹,吵口打架,私自离岗,窜岗,吃零食等行为,违者依员工奖惩制度处理。

      12.作业时间谢绝探访及接听私人电话,确保产品质量

      13.任何人不得携带违禁物品,危险品或与生产无关之物品进入车间;不得将私人用品放在生产线上,违者依员工奖惩制度处理

      14.车间严格按照生产计划安排,根据车间设备状况和人员,精心组织生产。生产工作分工不分家,以团队利益为最终的奋斗目标,各生产班组须保质保量的完成生产任务

      15.员工领取物料必须通过物料员,不得私自拿取,操作员不得私自挪用物料。生产过程中各班组负责人将车间区域内的物品、物料有条不紊的摆放,并做好标识,不得有混料的现象发生

      16.生产流程经确认后,任何人均不可随意更改,如在作业过程中发现有问题(还有更好的可改进的方案),应先通知有关部门负责人共同研讨,经同意并签字后方可更改

      17.在工作时间内,员工必须服从管理人员的工作安排,正确使用公司发放的仪器、设备。对闲置生产用具应送到指定的区域放置,否则以违规论处

      18.车间员工必须做到文明生产,积极完成上级交办的生产任务;因工作需要临时抽调,服从车间组长级以上主管安排,协助工作并服从用人部门的管理,对不服从安排的将上报公司处理

      19.员工有责任维护工作之环境卫生,严禁随地吐痰,乱扔垃圾。在生产过程中要注意节约用料,不得随意乱扔物料、工具,掉在地上的元件必须立即捡起来

      20.不得私自携带公司内任何物品出厂(除特殊情况需领导批准外),若有此行为且经查实者,将予以辞退并扣发当月工资。对恶意破坏公司财产或盗窃行为(不论公物或他人财产)者,不论价值多少一律交公司行政部处理。视情节轻重,无薪开除并依照盗窃之物价两倍赔偿或送公安机关处理。

      21.所有SMT人员必须严格遵守公司及部门的规章制度

    展开全文
  • 禅道需求管理规范

    万次阅读 多人点赞 2017-03-21 14:39:13
    需求管理规范 2 4.1 需求管理流程 2 4.2 需求开发指引 3 4.3 需求录入规范 6 4.4 需求评审规范 7 4.5 需求计划规范 7 4.6 需求关闭规范 7 4.7 需求变更 8 1版本记录 2目的 目前存在需求描述不明确,录入、评审不...

     

     

    1 版本记录

     

    2 目的

    目前存在需求描述不明确,录入、评审不规范等问题,本文档的目的是通过需求管理规范化,确保团队的成员在项目过程的做符合项目目标的事,以便提高团队的整体效率,及时完成项目的目标,交付可用的产品。

    3 阅读对象

    研发中心全体人员。

     

    4 需求管理规范

    4.1 需求管理流程

    禅道软件设计的需求有两个字段来跟踪它的变化,一个是需求的状态字段,一个是需求的研发阶段字段,下面来看下这两个字段。

    需求的状态及状态管理

    需求状态(status)字段,总共有四种状态,分别是草稿(draft)、激活(active)、已变更(changed)和已关闭(closed)。对应为需求的流程操作共有:创建、变更、审核、关闭、激活,其状态流转图如下:

     

     

     

    需求的状态约定如下:

    1) 录入需求时必须要勾选“需要评审”,即需求默认处于草稿状态

    2) 草稿状态的需求由产品线负责人审核,审核通过后处于激活状态。

    3) 若需要变更的需求变更后会变成“已变更”状态

    4) 产品发布后,由产品经理关闭需求,变成“已关闭”状态。

     

    需求的研发阶段

    还有一个阶段(stage)字段,用来描述激活的需求在研发过程中所处的阶段。目前总共有未开始、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布

    需求的研发阶段是如何变化的呢,一种方案是通过编辑操作,来修改研发阶段(已立项之后可手动选择需求所处的阶段)。另外一种方案,就是在创建任务的时候,设置好任务的类型,比如开发,测试。禅道会根据不同类型任务的变化来自动计算需求的研发阶段,其规则如下:

    1. 如果需求没有关联到项目,也没有关联到计划,则需求的研发阶段是"未开始"。

    2. 如果需求关联到了计划,还没有关联到项目中,则需求的研发阶段是"已计划"。

    3. 如果需求关联到了项目中,但还没有分解任务,则需求的研发阶段是"已立项"。

    4. 如果需求关联到了项目中,且进行了任务分解:
    如果有一个开发任务进行中,并且所有的测试任务还没有开始,需求的研发阶段为“研发中”。
    如果所有的开发任务已经完成,并且所有的测试任务还没有开始,则为“研发完毕”。
    如果有一个测试任务进行中,则视为“测试中”。
    如果所有的测试任务已经结束,但还有一些开发任务没有结束,则视为"测试中"。
    如果所有的测试任务已经结束,并且所有的开发任务已经结束,则视为"测试完毕"。

    5. "验收"阶段是需要产品经理手工来进行确认的。

    6. 如果需求关闭,且关闭原因是“已发布”, 则需求的研发阶段是“已发布”。

    4.2 需求开发指引

    在禅道中,默认提供了一个需求的模板:作为一名<某种类型的用户>,我希望<达成某些目的>,这样可以<开发的价值>。这个模板是scrum开发里面的用户故事(user story)的写法。

     在这个模板中,总共有三个元素:

    角色:需要进行用户角色划分,不进行用户角色的划分,会影响对产品功能的设计和定位,从而导致产品往往是给一个用户角色开发的,就是产品经理自己

    要做的事情:平常只关注了要做的事情

    价值或者原因:需要强调,如果忽略开发的原因或者价值,会让开发人员感到困惑。他们可能并不理解这样做的原因或者目的,不理解的需求实现起来自然会有问题。

     

    一个编写良好的用户故事是敏捷开发的基础。它们应该相互独立,详情应该便于开发者和用户进行沟通,应该对用户有价值,应该对于开发者来说尽可能的清晰以便进行估计,应该短小,通过预定义测试用例的使用确保它是可以测试的。

     

    根据以上原则,不同的用户故事可参考下面的写法:

    操作故事:如“查看请求”

    -作为一个会议主席,可以查看到哪些用户在请求发言或主讲,以便及时处:理授权或拒绝,达到管控会议的目的。

    文件故事:如“购物车”

    -购物车用于存放客户有购买意向的产品,以便客户在购买多种产品时不需要多批次重复购买。

    增强一个操作:如“高亮显示发言次数最少的用户请求 “

    -实现后,作为一个会议主席,可以在查看请求时,突出的看到发言次数最少的请求,以便优先给他授权,达到一个尽量多的人发言的开会目的。

    增强一个文件:如“增加编辑购物车“

    -实现后,用户可以在购物车里选择清理掉暂时不购买的产品。

    重构:界面及交互方式更改 

    -实现前,不同的客户端界面不统一,交互方式也有差异;实现后,所有客户端使用统一的交互原型,以达到用户体验一致,增强产品的品牌统一风格。

    缺陷:如“有多用户同名时无法登陆的问题”

    -在不同企业存在相同的用户名的用户时,用户无法正常登陆,导致用户无法进入系统正常使用BOSS各项功能。

     

    除了上面基本的模板之外,在撰写用户故事的时候,可以参考INVEST原则

    · I dependent(独立的):一个用户故事对于另一个用户故事应该是独立的(尽可能的)。故事之间的依赖性使得增加了计划编制,确立有限级,故事估计这些工作非常困难。通常,可以通过组合用户故事或者分割用户故事来减少依赖性。

    · N egotiable(便于沟通的):一个用户故事是便于沟通的。一个故事的卡片是包含故事详情的简短描述。这些详情是通过讨论阶段来完成的。一张还有很多详情的卡片实际上减少了和客户的会谈。

    · V aluable(有价值的):每个故事必须对客户具有价值(无论是用户还是购买方)。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到一个用户故事并不是一个契约而且可以进行协商的时候,他们将非常乐意写下故事。

    · E stimable(可估计的):开发者需要去估计一个用户故事以便确定有限级并对故事进行规划。但是让开发者难以估计故事的问题来自:对于领域知识的缺乏(这种情况下需要更多的沟通),或者故事太大了(这时需要把故事切分成小些的)。

    · S mall(短小):一个好的故事应该在工作量上短小,描述具有代表性,而且不超过2-3人周的工作量。超过这个范围的用户故事,将会在划分范围和估计时出现很多错误。

    · T estable(可测试的) :一个用户故事是可测试的来用于确认完成,记住,我们不开发不能测试的故事。如果你不能测试那么你永远不知道你什么时候是完成了。一个不可测试的用户故事例子:软件应该是易于使用的。

    需求和原型图、需求设计文档的区别

    传统管理模式中,很多产品经理都在用原型图软件设计原型图或者非常完整的需求设计文档。设计完之后,交给设计人员进行页面设计,然后由开发人员合并代码。那么原型图和用户故事之间的关系和区别是什么呢?

    · 和user story相比,原型图或者需求设计文档是一个整体,可以给人宏观的把握。这是原型图的优点。比较直观。

    · 它是一个整体,所以就没有办法进行分解。你不可能分解成,做页面导航条,做页面的中间部分等。

    · 没有分解,所以原型图也就没有办法进行优先级的排序。比如页面部分,有的很重要,有的不重要。但在原型图里面是体现不出来优先级的。

    · 没有分解,自然也就无法进行跟踪。你没有办法得知原型图完成了多少。

    · 过于死板,给设计人员和开发人员留下的发挥的空间太少,最后演变成被动执行。

    · 需求设计文档规定的比较细致,会让产品经理陷入太多的细节,对整体的把握会减弱。

    · User story与文档化的需求相比,开发人员面对的就不再是文档化的功能点,而是可追溯的,易跟踪的以及结构化的功能点

    虽然相比较于用户故事而言,传统的原型图或者需求设计文档有一些不足,但在实际的开发过程中,二者可以相辅相成。可以将原型图作为设计文档,上传到某一个产品相关的文档库中,和用户故事相互配合,是一个最好的方案了。

    4.3 需求录入规范

    将需求录入禅道时,需要遵守以下规范:

    1) 调研清楚用户提出问题背后的需求,将需求分解成为一个个用户故事。

    2) 录入前,先在禅道中查找该需求的关键词,以避免录入重复的需求。

    3) 明确需求的分类及对应的产品模块,如果不确定,可以找研发一起讨论。

    4) 需求描述需要规范,需要把具体用户、用户愿望、用户的价值说明清楚。

    务必将需求、用户的愿望、任务区分开。

    如下图,是一个愿望的描述,需求所创造的价值不清晰。

     

    规范的描述方式:

    5) 验收标准需要产品经理描述清楚,前置条件是充分理解用户的需求及解决方案后来确定的。

    每条需求的创建者,务必把验收标准描述清楚,这样可以把需求的输出给说清楚,同时也可以体现该需求实现的可行性有高度的保障。

    6) 需求的优先级按以下规则:

    a) 重要&紧急,列入1级;

    b) 重要&不紧急,列入2级;

    c) 不重要&不紧急&不确定,列入3级;

    d) 其他列入4级。按1:5:2:2的比例来分配,开发的计划基本都是从1级和2级提炼出来。

    7) 产品线负责人需要及时关注未进入开发的需求,并及时调整需求的优先级。

    8) 如果需求的描述不够规范清晰,可以通过“编辑”或“备注”进行完善修改。如果是导致实现上的变更,需要走变更流程。详见下面的章节。

    4.4 需求评审规范

    因为涉及到需求录入是否规范、对需求的理解是否准确的问题,所以每一条需求都需要产品线负责人进行审核。如果不符合要求,则需要重新录入或修改。

    1) 如果是符合产品年度规划、版本计划、实现方案明确的由产品线产品经理审核。

    4.5 需求计划规范

    1) 需要明确到两个版本计划,当完成第一个版本的需求后,产品经理需要明确下个版本的计划,并组织研发团队进行评审。

    2) 版本的计划要在项目启动前落实,产品线产品经理通过邮件的方式,把该版本的计划描述清楚,通知团队成员及相关人员知悉并确认。

     

    4.6 需求关闭规范

    需求完成了功能验证之后,需要将其阶段变为“已验收”,

     

    待产品发布的一周后,要将相关的需求状态设为“已关闭”。

    4.7 需求变更

    需求的变更分为两种,一种是需求评审前的变更,一种是需求评审后的变更。两种需求变更的说明如下:

    1) 评审前的需求变更直接到禅道的需求的变更里面修改即可。只需要在需求的备注部分说明清楚。

    2) 评审后的需求变更需要在禅道中走需要变更的流程,并更新项目需求规格书上的相应需求。

    禅道中需求变更的流程:

     

     

     

    展开全文
  • 软件版本管理规范

    万次阅读 2016-11-10 10:29:57
    软件版本管理规范版本:1.0 第一章 目的 本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容,使软件项目版本管理流程化并规范化,确保在系统开发和实施过程中项目的完整性和一致性。 第二...
    1. 第一章 目的
      本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容,使软件项目版本管理流程化并规范化,确保在系统开发和实施过程中项目的完整性和一致性。
    2. 第二章 适用范围
      所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库(可使用工具建立配置库,本文所述使用的是SVN)进行版本管理。
    3. 第三章 职责
      配置库管理员:负责配置库的日常维护和管理;监督开发及测试部门及时提交版本管理对象(即配置项)。
      此岗位可由开发或测试人员兼任。
    4. 第四章 内容
      4.1. 版本管理对象
      包括但不限于:
       项目总体计划
       可行性研究报告
       开发计划
       需求说明书
       需求设计原型
       设计说明书
       系统开发变更申请单
       系统管理手册
       用户操作手册
       培训计划
       培训记录
       源程序
       支持系统运行的配置文件
       存储过程脚本
       测试计划
       测试用例
       测试脚本
       测试报告
       上线计划
       上线申请
       版本维护日志

    4.2. 配置库的目录结构
    每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目内部的目录结构建议按下列格式创建。
    配置库目录结构规划:
    ┠tags(发布)
    ┃ ├v1.0.0_T1_2016909
    ┃ ├v1.0.0.33899_T1_20161009
    ┃ ├v1.0.0_R1_20161109
    ┃ ├v1.1.0_T1_20170109
    ┃ └v1.1.0_R1_20170209
    ┠trunk(主版本)
    ┃ └projectA
    ┃ ├src
    ┃ ├MY_MOOC
    ┃ ├doc
    ┃ ├tool
    ┃ ├。。。
    ┖branches(分支)
    ├SY_ABC
    ├TJ_ABC
    ├WH_MOOC
    其中,项目内部的目录结构:
    |–projectA
    |–src (保存该项目的源程序)
    |–doc (保存项目相关文档)
    |–000.项目管理 (保存项目过程管理相关文档)
    |–010.项目计划 (保存项目计划相关文档)
    |–020.项目需求 (保存项目需求相关文档)
    |–030.系统设计 (保存项目设计相关文档)
    |–030.系统测试 (保存项目代码测试相关文档)
    |–040.系统实施 (保存项目部署实施相关文档)
    |–050.系统运维 (保存项目运维文档,包括培训、用户手册等)
    |–060.技术资料 (保存项目技术文档,包括第三方技术资料等)
    |–。。。 (保存项目过程管理相关文档)
    |–tool (包括该项目特定的开发、编译、测试等工具)
    4.3. 分支(branch)
    建议使用分支来协同不同职能小组对同一个配置库的使用,可按照以下方式进行分支的管理。
    解决方案建立三个分支,包括主版本开发(trunk)、分支版本开发(branches)和发布(tags)。
     主版本开发
    是所有分支版本的基准版本,主版本的开发分支。开发部门开发使用。
     分版本开发
    主版本的分支版本,供开发部门开发使用。开发工程师如果以主版本为基准,进行软件项目开发,要先将trunk目录下的代码分支到branches目录的一个子目录,在那里对代码进行开发。多个主版本的分版本可通过在branches顶级目录创建多个分支目录来区分。
     发布
    测试和发布专用分支,该分支代码不允许任何形式的修改。每个经过测试后的不同版本的代码做快照放到此分支文件夹下。
    4.4. 权限管理
    应对配置库的访问权限进行管理,确保软件系统的完整性和安全性。建议按如下方式进行管理。
    4.4.1. 开发工程师
    仅拥有自己所属项目的add file、delete file、check out、check in权限,无目录创建和删除权限。开发工程师若想创建目录,需向配置库管理员申请。
    4.4.2. 测试工程师
    拥有每个项目的测试分支的add file、delete file、check out、check in权限,无目录创建和删除权限,对于其他分支只有只读权限。
    4.4.3. 配置库管理员
    拥有全部权限,但增删项目和增删目录需要有项目负责人批准。
    4.4.4. 其他人员
    若需要配置库访问权限,需经技术总监或经技术总监授权的项目经理批准,由配置库管理员分配权限。
    4.5. 版本管理
    应对软件系统的版本进行管理,确保版本的准确性和可追溯性。建议按如下方式进行管理。
    4.5.1. 版本维护
    软件工程各阶段产生的各种文档和代码,应及时并统一上载到配置库由配置库管理员统一管理。对于要修改的配置项,应从配置库中检出(check out)后修改,修改完毕后及时检入(check in),并填写修改的原因和内容。配置项的历史版本应保存在配置库中。
    4.5.2. 分支迁移
    从开发分支到测试分支的迁移,由开发工程师操作。迁移的时机有:
    1. 当开发负责人提交测试申请时;
    2. 开发过程中进行测试,修改好一个或多个bug,需要测试工程师验证时。
    从测试分支到发布分支的迁移,由配置库管理员操作。迁移的时机有:
    1.当开发组提交上线申请时。
    对于每个项目从测试分支到发布分支的迁移,配置库管理员要建立分支迁移日志,并详细记录。
    4.5.3. 版本升级
    软件系统迁移到发布分支后,生成新的版本。
    每个系统新的版本不仅以分支形式存在于配置库中,并且要以独立压缩包形式备份。
    版本的命名规则为,version N1.N2.N3[.N4][_][T/R5]_YYYYMMDD
    1. N1是系统编号。当项目整体重新设计时,N1加1,基数为1
    2. N2是模块编号。当模块重新设计时,N2加1,基数为0
    3. N3是功能编号。当项目增加某一功能,或某一功能需要修改时,N3加1,基数为0
    4. N4是BUG编号。当项目的BUG被修复时,N4加1,基数为0
    5. T/R5中的T/R分别对应Test/Release。当项目发布时为R,当项目提交测试时为T,T/R5数值基数为0,以发布/测试提交顺序递增加1 。
    6. YYYYMMDD代表生成版本的实际年月日,如:20160202
    4.5.4. 版本基线定义
    公司首次采用版本管理规范时,可以采取下列方法定义一个基线版本。
    获取各项目最新的源程序、配置文件和文档,形成发布分支、测试分支和开发分支。
    对每个项目的提测和发布分支都生成一个版本基线,如:Version1.0.0_R1_20160202。
    4.6. 第五章 版本提交准则
    4.6.1. 提交之前先更新
    更新的原则是要随时更新,随时提交。当完成了一个小功能,能够通过编译并且自己测试之后,谨慎地提交。
    如果在修改的期间其他同事也更改了同一个文件,那么update更新时会自动进行合并,如果修改的是同一行或者二者修改差异过大,那么合并时会产生冲突。这种情况就需要同之前的开发人员联系,两人一起协商解决合并冲突。解决合并冲突之后,还需要两人一起测试,以保证解决冲突之后,各自的程序不会受到影响。
    在更新时注意所更新文件的列表,如果提交过程中产生了更新,则需要重新编译并且再次完成单元测试,再进行提交。这样既能了解别人修改了哪些文件,同时也能避免合并错误导致代码有错。
    4.6.2. 保持原子提交
    为确保在需要时可以随时回溯代码版本,每次提交的代码只能包含实现一个独立、完整功能所必需的代码,不能夹带提交其他与此功能不相关的代码。为尽早提交,也可以将此独立、完整功能分解为若干小细节功能,分别开发并提交所必需的代码,但必须确保多次提交的功能代码组合在一起,完全实现此独立、完整功能。
    仅提交自己修改的部分,最好不要一下子将整个项目提交。
    每完成一个独立、完整的功能后,最好尽早提交,以免后续更改时出现bug,无法恢复到正常代码。
    每次提交的间歇尽可能地短,以几个小时的开发工作为宜。我们提倡多提交,也就能多为代码添加上保险。为做到尽早提交,在开发功能模块的时候,先将功能分解成一个个独立的、不可再分割的小细节功能,分别完成。每完成一个并通过单元测试,就提交一次。在修改bug的时候,每修改掉一个bug并且确认修改了这个bug,也就提交一次。
    4.6.3. 不要提交本地自动生成的文件
    一般配置管理员都会将项目中一些自动生成的文件或者与本地配置环境有关的文件屏蔽提交(例如Eclipse中的.classpath文件等,Visual Studio中的.suo文件,Debug,Release,Obj等编译文件夹及其下文件,以及其他的一些自动生成,同编译代码无关的文件)。如果项目中没有进行这方面的配置来强行禁止提交这样的文件,请自觉不要提交这样的文件,如果不小心签入了,需要从配置库中删除,以免其他同事在更新后就可能与本地的环境冲突从而影响大家的工作。
    4.6.4. 不要提交不能通过编译的代码
    代码在提交之前,首先要确认自己能够在本地编译通过,并且代码在提交前已经通过自己的单元测试。
    如果在代码中使用了第三方类库,要把相应类库文件统一存储在代码相应目录中并提交,以免项目组成员中有些成员可能没有安装相应的第三方类库,从而在更新代码后引起代码运行错误。
    4.6.5. 不要提交自己不明白的代码
    代码在提交之后即被项目成员所分享。如果提交了不明白的代码,自己看不懂,别人也看不懂,如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前,确保对这个代码有一个很清晰的了解(必要时应有对应文档说明)。
    4.6.6. 并行开发(同一模块)前沟通
    如果开发小组采用并行开发模式开发同一模块功能,在开发前,需要对协作开发进行合理的工作计划与任务分配,让小组成员相互间了解对方的工作计划与工作内容。这样能尽可能的减少在开发过程中可能出现的冲突,提高开发效率。同时也能够在和成员的交流中发现自己之前设计的不足,完善自己的设计。
    4.6.7. 对提交更新的信息采用明晰的标注
    如果提交空的标注或者不确切的标注将会让项目组中其他的成员不了解此次签入动作的背景情况(如新增/修改签入的原因是什么?新增/修改什么内容?),项目经理无法通过提交的标注信息,清晰的掌握开发工作进度细节进度。没有清晰标注,甚至会对回溯代码版本造成影响。所以,在提交工作时,要填写明晰的标注,能够概要的描述所提交文件的信息,让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。

    统一的标注格式为:
    签入动作+””+”#” +标识ID+”;”+签入内容+[“;”]+[签入原因]
    签入动作:
    +:表示增加了功能(新增功能)
    *:表示对某些功能进行了更改(修改功能)
    -:表示删除了文件,或者对某些功能进行了裁剪,删除,屏蔽(删除功能)
    ^:表示修正bug(修复功能缺陷)
    !:优化功能代码的执行性能(代码性能优化)
    标识ID:
    ID值是从项目开发计划中的WBS任务分解表中获取,对应具体功能编号。
    签入内容:
    对新增/修改/删除 的内容进行简单描述
    签入原因:
    对修改/删除 的原因进行简单描述
    示例:
    + #62235;新增房源审核功能
    * #62236;将房源审核的二级审核修改为一级审核;为缩短业务流程长度,提高业务响应速度
    - #62237;删除多余功能;房源审核由二级审核改为一级审核后删除无用功能
    ^ #108;房源主图显示尺寸控制为300*300;房源主图显示尺寸撑大页面

    结束。

    展开全文
  • 配置库管理及版本管理规范

    千次阅读 2019-01-08 19:50:56
    配置库管理及版本管理规范               版本信息 A代表新增,M代表修改,D代表删除。 版本号 发布日期 提交人 A.M.D 摘要 V...

     

     

     

     

     

     

     

    配置库管理及版本管理规范

     

     

     

     

     

     

     

    版本信息                                       A代表新增,M代表修改,D代表删除。

    版本号

    发布日期

    提交人

    A.M.D

    摘要

    V1.0

    2019/1/8

    杨彬彬

    A

    初稿

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    配置库管理及版本管理规范 1

    1. 前言 4

    1.1. 目的 4

    1.2. 配置库代码管理工具 4

    1.3. 角色和职责 6

    2. 配置仓库管理 7

    2.1. 配置仓库说明 7

    2.2. 配置仓库管理规范 8

    2.3. 配置仓库权限管理 9

    2.4. 灾备策略 12

    2.5. 灾备还原 12

    3. 分支管理规范 12

    3.1. 分支工作流程图 13

    3.2. 分支职责 13

    3.3. 创建分支规范 14

    3.4. 分支命名规范 15

    4. 代码管理规范 15

    4.1. 提交代码规范 15

    5. 版本管理规范 17

    5.1. 目的 17

    5.2. 项目版本管理 18

    5.3. 软件产品包版本管理 18

    5.4. 出包步骤 19

     

    1. 前言 
      1. 目的
    1. 规范项目代码管理流程,明确开发人员和项目管理者的职责。
    2. 规范代码库分支管理和版本管理,使代码分支及版本结构清晰,方便维护。
      1. 配置库代码管理工具 
        1. Git介绍

    使用GitLab作为代码管理工具,GitLab 是一个用于仓库管理系统的开源项目,使用Git作为代码管理工具,并在此基础上搭建起来的web服务。

    Git是一个开源的分布式版本控制系统,用以有效、高速的处理从很小到非常大的项目版本管理。可以实现数据备份、记录历史、回到过去、多端共享、分工合作。

        1. Git分层结构

     

    git的工作总共分四层,其中三层是在本地,包括了工作目录,暂存区和本地仓库。

    工作目录

    执行命令git init时所在的地方,也是执行一切文件操作的地方。

    暂存区:

     在.git文件夹目录中,在工作区和版本库中间起缓存作用的一个区域。它通过git add命令添加进暂存区。存储了一些即将被commit的文件。

    本地仓库

    在.git文件夹目录中,使用了git commit命令之后添加进的真正的“仓库”。里面存储了每次commit的记录,每次commit一次会让HEAD指针指向新的目录树,而旧的目录就存在版本库中,可以使用命令来提出之前的目录树。

    git所存储的都是一系列的文件快照,然后git来跟踪这些文件快照,发现哪个文件快照有变化它就会提示你需要添加到暂存区或是提交到本地仓库来保证你的工作目录是干净的。

    进入工作区.git文件夹,如下.git目录或文件结构说明:

    目录或文件

    说明

    config文件

    项目的配置文件,里面有中心服务器的信息和分支信息。

    HEAD文件

    指向当前的分支。

    index文件

    暂存区的相关信息。

    logs目录

    相关操作产生的日志。

    objects目录

    存储的就是所有的数据,也就是快照。 存放的是实际上的文件资源,每次当使用了git add命令之后,就已经把文件存到了objects目录里面。objects目录中的object对象都有一个通过哈希算法计算出来的40位16进制的id,前两位是目录名,后38位是文件名。因为哈希算法可以只比较哈希值,就能知道这两个对象是不是一样的,这样可以提高效率。    

    refs目录

    存储指向数据提交对象的指针。

        1. 工作流程

      1. 角色和职责

    角色名称

    职责

     配置管理员

    1. 管理配置服务器,维护代码仓库、安全设置,定期备份代码仓库。
    2. 负责为项目提供全面的配置管理基础设施和环境。包括代码仓库建立、人员添加等工作。
    3. 编写和维护配置管理的相关文档,包括服务器配置管理方法、配置工具使用方法等。
    4. 编写培训材料,制定培训计划,对开发人员和项目管理人员进行配置管理工具使用培训。
    5. 负责构建release发布版本。并解决或指导开发人员解决合并冲突。
    6. 负责解决在使用配置管理工具过程中遇到的问题。

      开发负责人

    1. 管理源代码,构建代码框架,导入配置服务器。
    2. 在配置管理员协助下对源代码进行管理。
    3. 负责同意master分支的合并请求。
    4. 根据项目进展制定开发基线,管理版本编号以及分支版本,必要的时候,负责版本的合并。

      开发人员

    1. 从服务器克隆项目,按照分配的任务,进行分工协同开发。
    2. 从服务器获取代码库最新变更,在自己负责的模块中加入、修改或删除文件。
    3. 及时提交代码到开发分支并附加变更说明。
    4. 负责构建SIT环境版本。

    测试负责人

    1. 制定测试计划
    2. 确认条件不允许时的例外放行。
    3. 跟踪并报告测试工作的进展,发布后撰写测试总结报告,对测试遗漏的问题进行分析。

    测试人员

    1. 编写测试计划、规划详细的测试方案、编写测试用例
    2. 根据测试计划搭建和维护测试环境
    3. 执行测试工作,提交测试报告。包括编写用于测试的自动测试脚本,完整地记录测试结果,编写完整的测试报告等相关的技术文档。
    4. 对测试中发现的问题进行详细分析和准确定位,与开发人员讨论缺陷解决方案。
    5. 提出对产品的进一步改进的建议,并评估改进方案是否合理;对测试结果进行总结与统计分析,对测试进行跟踪,并提出反馈意见。

     

     

    1. 配置仓库管理
      1. 配置仓库说明

         配置管理员负责建立配置仓库,以便管理源代码、相关文件及资料。每个开发人员在本地都有自己的版本库,在服务器上有一个公共的版本库。

      1. 配置仓库管理规范

    根据配置管理的不同角色所分配的不同职责范围,对本地库和版本库进行管理和操作。

        1. 远程仓库管理
    1. 配置管理员:创建远程仓库、人员添加、权限分配、打标签、构建版本等工作。
    2. 开发负责人:导入该项目到远程仓库并完成分支的创建和设置。
        1. 本地仓库管理

    本地库由开发人员和开发负责人负责日常的更新和开发工作。

    1.  克隆远程仓库,搭建开发环境

    开发人员根据配置管理提供的git访问地址,将远程仓库克隆到本地,使工作区可以正常运行起来,并根据分支策略在开发分支上创建分支进行开发工作。

    1.  代码提交

    开发人员修改完成后提交代码到暂存区,在暂存区域生成文件快照并提交到本地和远程开发分支,由开发负责人来进行代码的审核和合并。建议开发人员及时同步代码,以避免冲突和丢失修改。同时,开发人员必须保证上传的代码是通过编译的。

    在开发过程中,很多时候需要对一个项目进行分支操作,在开发分支上对项目进行开发。这由开发人员负责执行。

      1. 配置仓库权限管理
        1. 添加用户

    新员工入职后,如需配置库权限,可走OA或邮件(抄送部门领导)发送给配置管理员申请权限,待领导同意或OA审批通过后,配置管理员为其创建用户并分配对应权限。用户名生成规则为邮箱前缀。

        1. 创建

    默认只有配置管理员有权限进行群组的创建与编辑(可建子群组),如有需要可提OA或邮件(抄送部门领导)发送给配置管理员申请权限,待领导同意或OA审批通过后,配置管理员为其创建群组或调整相应权限。邮件或OA里面需要注明具体信息,如:创建群组的名称,或调整群组的具体权限信息等。

        1. 用户权限

    如需配置库权限,可走OA或邮件(抄送部门领导)发送给配置管理员申请权限,待领导同意或OA审批通过后,配置管理员为其创建用户并分配对应权限。邮件或OA里面需要注明申请的具体信息,如:

    姓名:xxx

    群组名与角色:atp-bos  master

    项目名与角色:ATP/Common  develop

    权限截止日期:2019-07-08(永久权限不写此项)

    不同角色拥有不同权限,下面列出Gitlab各角色常用权限

    1. 工程权限

    行为

    Guest

    Reporter

    Developer

    Master

    Owner

    创建issue

    留言评论

    更新代码

     

    下载工程

     

    创建代码片段

     

    创建合并请求

     

     

    创建新分支

     

     

    提交代码到非保护分支

     

     

    强制提交到非保护分支

     

     

    移除非保护分支

     

     

    添加tag

     

     

    创建wiki

     

     

    创建里程碑

     

     

     

    添加项目成员

     

     

     

    推送保护分支

     

     

     

    是否保护分支

     

     

     

    修改/移除tag

     

     

     

    编辑工程

     

     

     

    添加deploy keys

     

     

     

    配置hooks

     

     

     

    切换visibility level

     

     

     

     

    切换工程namespace

     

     

     

     

    移除工程

     

     

     

     

    移除保护分支

     

     

     

     

     

    1. 群组权限

    行为

    Guest

    Reporter

    Developer

    Master

    Owner

    浏览组

    编辑组

     

     

     

     

    创建项目

     

     

     

    管理组成员

     

     

     

     

    移除组

     

     

     

     

        1. 保护分支

    默认保护master分支,可使用正则表达式保护分支。保护的分支不能进行push -f操作。

        1. 项目的可见性

    项目的可见性不能超出群组的可见性范围,项目或群组有三种可见性:

    Private:私有,必须配置权限才可进行访问。

    Internal:内部,必须进行帐号密码登录后才可进行访问。

    Public:公开,所有人都可进行访问。

        1. 移除用户

    定期清理已离职或调出项目的成员权限

      1. 灾备策略

    <暂无>

      1. 灾备还原

    <暂无>

    1. 分支管理规范

    本公司采用git flow工作流模式进行分支管理。

      1. 分支工作流程图

    图 3-1 git flow工作流程图

      1. 分支职责
    1. 主分支master

    代码库应该有一个、且仅有一个主分支。它是自动建立的,一般默认此分支是被保护的,版本库初始化以后,就是在主分支在进行开发。此分支除第一次进行原子提交推送外,只能接收其它分支合并,任何人不能直接在master分支上进行修改和提交。

    1. 开发分支develop

    用于日常开发,存放最新的开发版的一个主要分支。不管是要做新的feature还是需要做bug fix,都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本,即完成了某个feature或者修复了某个bug后的开发稳定版本,开发完成需要提交测试的功能都必须要合并到该分支。

    1. 辅助分支

    feature: 开发新功能的分支, 基于 develop, 完成后 merge 回 develop。

    release: 准备要发布版本的分支, 用来修复 bug. 基于 develop, 完成后 merge 回 develop 和 master;

    hotfix: 修复 master 上的问题, 等不及 release 版本就必须马上上线. 基于 master, 完成后 merge 回 master 和 develop。

      1. 创建分支规范

    1.配置管理员在建立仓库时创建一个master分支和develop分支。

    2.开发人员根据开发的功能点从develop分支创建一个feature分支,当功能点开发测试完毕之后,就会合并到develop分支去,可以将feature分支删除。

    3.当需要发布一个版本来测试时,开发人员从develop分支创建一个release分支来测试。

    4.正式发布后,过程中出现bug,从master分支创建一个hotfix分支,修补结束以后,再合并进master和develop分支。

      1. 分支命名规范
    1. 主干分支:master
    2. 开发分支:develop
    1. 创建特性分支,名称要以f-开头,加上特性名
    2. 创建发布分支,名称要以r-开头,加上预发布版本号
    3. 创建Bug修复分支,名称要以b-开头,加上Bug号
    1. 创建标签:
    1. 当软件包发布到UAT环境时要在release分支上打标签,名称要以发布版本号加上RC1,RC2等结尾。
    2. 当软件包发布到正式环境后要在master分支上创建标签,名称要以发布版本号加上REALESE结尾。
    1. 代码管理规范
      1. 提交代码规范
        1. 目的

    为了规范代码库分支管理和版本管理,使代码分支及版本结构清晰,方便维护,并避免由于维护造成的错误的版本发布等问题。

        1. 代码提交说明

    由对应分支修复的实际开发人员提交或合并到开发分支,开发负责人需要进行判断是否需要合并,并协助解决冲突代码。提交的信息必须按照代码提交模板规定来书写。

        1. 代码提交模板

    Commit message格式:

    type(scope): subject

    BugID:如果是修复Bug,请加上Bug号

     

    type: 用于说明 commit 的类别,暂时只使用下面标识(后续可完善增加)。

    feat:

    新功能(feature)

    fix:

    修补bug

    docs:

    文档(documentation)

    style:

    格式(不影响代码运行的变动)

    refactor:

    重构(即不是新增功能,也不是修改bug的代码变动)

    chore:

    构建过程或辅助工具的变动

    test:

    测试用例的修改

    ci:

    自动化流程配置修改

    revert:

    回滚到上一个版本

    Other:

    其它

     

    scope:【可选】用于说明commit的影响范围

    subject

    subject是 commit 目的的简短描述,不超过50个字符。

    例如:

    feat(ssr): 增加可视化功能

    BugID:8023

        1. 代码提交步骤

    1. 同步远程仓库代码,和远程仓库进行代码合并。

    2. 将分支工作区修改的代码和提交描述等提交到开发分支。

    3. 开发负责人对提交的分支代码进行审核和合并,并解决冲突。

    4. 同步到主分支上。

        1. 解决冲突

    pull同步工作区,找到冲突文件,解决冲突重新提交。

    1. 版本管理规范 
      1. 目的

    标识、控制和追踪软件开发和实施过程中产生的各种软件产品版本。

      1. 项目版本管理
        1. 版本号约定

    <主版本>.<次版本>.<增量版本>-<SNAPSHOT>

    主版本:标示项目的重大架构变更。

    次版本:表示重大Bug的修复,较大范围的功能增加和变化。

    增量版本:一般标示一些小的bug fix,不会有重大的功能变化。

    SNAPSHOT:快照版本,只能用于开发阶段对内发布,对外发布时不允许出现SNAPSHOT版本。

    eg:1.3.4-SNAPSHOT

    【1】代表该版本是第一个重大版本;

    【3】表示这是基于重大版本的第三个次要版本;

    【4】表示该次要版本的第四个增量版本;

    【SNAPSHOT】表示此版本为快照版本;

     

    版本号的修改由开发人员根据以上规则进行更改。

      1. 软件产品包版本管理

    预发布环境:V主版本号.子版本号.增量版本号_日期版本号(yyMMdd)_阶段版本号

    如:V2.15.0_190108_RC1

    正式环境:V主版本号.子版本号.增量版本号_日期版本号(yyMMdd)_RELEASE

    如:V2.15.0_190108_RELEASE

     

    主版本号:当功能模块有较大的变动,比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。

    子版本号:当功能有一定的增加或变化,比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。

    增量版本号:一般是 Bug 修复或是一些小的变动,要经常发布修订版,时间间隔不限,修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。

    日期版本号:用于记录修改项目的当前日期,每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。

    阶段版本号:此版本号用于标注当前版本的软件处于哪个开发阶段,当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。

     

    当软件包正式发布客户后需要配置管理员进行归档操作。

      1. 出包步骤
    1. 项目负责人通知项目组准备出包,同时给出出包时间点,如半小时后出包。
    2. 开发人员收到出包通知后,尽快将完成的代码进行提交到特性分支,并将特性分支代码合并到develop分支。
    3. 提交代码完成后,配置管理员基于develop分支拉release分支,并在构建时根据标签命名标准构造新标签号。如构建失败则通知开发人员在release分支上修改后重新构建。
    4. 通过maven和jenkins进行构建、打包和发布部署。
    5. 构建完成后通知相关人员。

     

    展开全文
  • Git分支管理规范

    千次阅读 2018-07-07 23:05:27
    前言:前几天,突然想起以前接触的项目,就想拉取下来看看,可是由于以前对代码的管理不注重规范化,提交记录也是随意...介于这种情况,今天,闲来没事,就来谈谈git分支管理规范吧,希望对大家工作以及项目的管理...
  • 随着信息系统复杂性的增加,对中国移动企业内部用户权限的管理要求,将大大超过手工管理跨异构系统的能力。管理上的复杂性还会导致出错机会和安全风险的增加。比如,人员的快速流转导致系统中大量存在孤立的账号,...
  • 网站项目管理规范指南

    千次阅读 2012-04-18 17:49:18
    这是网站项目管理规范指南2001,大家补全 作者ajie 1. 概述  关于本指南的目的,大纲描述。 1.1 什么是网站项目管理规范指南  《网站项目管理规范指南》读做“网站-项目管理-规范-指南”,顾名思义就是针对...
  • 国家分级保护规范要求解读

    万次阅读 2015-10-08 11:27:31
    仅就项目建设流程而言,涉密信息系统建设使用单位应依据《涉及国家秘密的信息系统分级...BMB20-2007《涉及国家秘密的信息系统分级保护管理规范》和BMB23-2008《涉及国家秘密的信息系统分级保护方案设计指南》设计系统
  • 国标:PAAS应用程序管理要求

    千次阅读 2019-02-26 19:55:33
    结合PaaS的参考架构,从不同角色所需功能,以及应用程序开发/部署/管理/配置/获取多方面进行了细节要求,同时防止用户被Vendor Lock特地设立迁移应用程序相关内容要求。如果能够出台更加具体的PaaS平台相关的建议...
  • 项目过程管理(三)文档组织规范

    千次阅读 2019-02-28 16:11:49
    所有文档以在线文档系统(Online Documentation System,下文简称ODS)为中心进行管理,ODS不方便存放的东西才放到SVN(或Git)。因为ODS有URL链接可以点击直达,比起基于电脑文件系统的管理方便得多,且直接支持...
  • 前言:本标准是由ISO(国际标准化组织)制定的,ISO...标准没有强制完全按照体系的要求执行,可以灵活变通,但标准是最低要求,可以保证质量的下限;标准采用过程方法,以过程管理为核心,结合了PDCA循环(所有的...
  • 版本管理和上线操作规范

    千次阅读 2018-09-19 15:44:08
    Git版本管理规范 新功能开发时,最先开始开发的人员务必基于远程主分支新建分支进行开发,所有正在开发阶段的功能,远程仓库都应有相应的分支; 新功能分支命名时,不得与远程仓库任何其他分支重名; 开发中的功能...
  • Git版本管理规范

    千次阅读 2018-04-04 13:45:02
    流程描述:目前有主分支master branch 和开发分支develop branch ,主分支和开发分支是受保护的,开发者不能直接对其进行开发工作,只有项目管理者(通常是项目的发起者)能对其进行较高权限的操作。协同开发过程...
  • Git分支管理及命名规范

    万次阅读 2018-05-17 11:24:45
    以上为笔者在开发过程中对git管理的个人理解,git管理并没有强求这个那个分支什么时候提交什么时候销毁,只要能更好地管理你的项目代码,什么git模式,you happy jiu ok ~~~ ok!!!到此为止,非常遗憾地告诉你...
  • NCC项目搭建及版本管理规范手册

    千次阅读 2020-02-11 18:46:14
    NCC项目搭建及版本管理规范手册 1. 项目工程要求 NCC项目搭建严格要求一个项目前后端各只有一个项目。 新项目首次开发时,由项目开发人员创建新工程,并且联系管理员创建gitlab项目进行关联。 项目二次合同开发时,...
  • 各阶段实施过程中,可参考的规范性标准依据如下: 系统定级阶段:《信息系统安全保护等级定级指南》 安全保护:《信息系统安全等级保护基本要求》、《信息系统安全等级保护实施指南》 检测评估:《信息系统安全...
  • 产品配置管理操作规范

    千次阅读 2015-02-28 10:28:29
    产品配置管理操作规范  目 录 1. 开发库结构规范. 6 1.1. 概述. 6 1.2. 开发库结构规范. 6 2. 帐号命名规范. 6 2.1. 概述. 6 2.2. 开发库帐号命名规范. 6 2.3. 交付库帐号
  • 接口测试相关文档管理规范

    千次阅读 2016-04-11 16:24:46
    3.1 测试文档范围 ...需求类的文档(如:接口说明文档)在测试初期由开发提供给测试人员,测试人员依据接口文档编写用例,文档不规范的地方需要及时向开发反馈,督促修改提供规范的接口文档。 测试用例文档是在
  • 二、管理要求 标记说明:保护数据在存储、传输、处理过程中不被泄漏、破坏和免受未授权的修改的信息安全类要求(简记为S);保护系统连续正常的运行,免受对系统的未授权修改、破坏而导致系统不可用的服务保证类...
  • 接口规范说起来大,其实也就那么几个部分,接口规范、接口管理工具、接口文档编写、开发文档编写。 接口规范定义 一、协议规范 为了确保不同系统/模块间的数据交互,需要事先约定好通讯协议,如:TCP、HTTP、...
  • 数据库设计规范化的 5 个要求

    千次阅读 2016-03-29 14:26:50
    数据库设计规范化的 5 个要求
  • 项目部署及版本管理发布规范

    万次阅读 2018-11-01 17:56:18
    为了保证系统稳定性运行,严格管理规范实施,制定本项目部署和版本发布规范。本规范用于规范平台的服务器端应用(包括APP后台、商家后台、管理后台和数据库)和APP的发布。 版本发布应流程包括项目部署前测试、...
  • 数据库操作管理规范(备份机制)

    千次阅读 2018-10-30 19:44:33
    9 数据库操作管理规范 9.1 备份机制 备份表命名规则:BAK_表名_月日时,月日时为两位数字。备份表名优先按此规则命名,超长允许备份表名缩写,但在备注中要写明全表名。 在备份表的备注中说明备份原因、备份组、备份...
  • 技术部的规范管理

    千次阅读 2007-08-16 15:52:00
    http://www.cooboy.com/index.php?job=art&articleid=a_20020708_123953我是作为公司技术部经理,因此技术部门的规范... 一、制定开发规范 对于技术管理工作,相信很多人比我有经验得多。在这里值得一提的是,建立规范
  • 软件工程师的基本要求,树立软件产业界整体优良形象: 0.01 自觉遵守公民道德规范标准和中国软件行业基本公约。  0.02 讲诚信, 坚决反对各种弄虚作假现象,不承接自己能力尚难以胜任的任务,对已经承诺的事,...
  • 淘宝虚拟物品类目管理规范

    千次阅读 2012-10-06 22:24:05
    发布部门: 规则文件类型:规范 修改时间:2012-08-03    编号:ⅡBC20120801Y0007    第一章 概述 第一条
  • 接口规范说起来大,其实也就那么几个部分,接口规范、接口管理工具、接口文档编写、开发文档编写。以下将详细介绍,下面进入正文:接口规范文档具体内容如下:一:协议规范二:域名规范三:版本控制...
  • 一篇文章搞定Git——Git代码管理及使用规范

    万次阅读 多人点赞 2019-05-22 17:55:25
    这三种分支都属于临时性需要,使用完以后,应该删除,使得代码库的常设分支始终只有Master和Develop。 四、 功能分支 接下来,一个个来看这三种”临时性分支”。 第一种是功能分支,它是为了开发某种特定...
  • SVN版本管理,提交代码规范

    万次阅读 2013-09-29 16:34:23
    SVN版本管理,提交代码规范 项目开发要求:  1、工作目录要及时更新,不要和SVN服务器有太大的差别 2、提交代码时,如果出现冲突,必须仔细分析解决,不可以强行提交 3、提交代码之前先在本地进行测试,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 336,550
精华内容 134,620
关键字:

属于管理规范的要求