UI团队文件及版本管理规范
系统版本管理
系统版本管理文档目录1. 引言 (1)1.1.目的 (1)1.2.范围 (1)1.3.术语定义 (1)1.4.参考资料 (3)1.5.版本控制记录 (3)1.6.版本更新记录 (3)2.版本管理 (4)2.1.版本标示方法 (4)2.1.1.正式版本 (4)2.2.目录结构 (5)2.3.文档的存放 (7)2.3.1.开发文档的存放 (7)2.3.2.源代码的存放 (7)2.3.3.SQL的语句存放 (7)2.3.4.发行文档的存放 (8)2.4.配置管理流程 (8)2.5.权限控制的管理 (8)3.更新管理 (9)3.1.源程序的修改 (9)3.2.版本升级 (10)3.2.1.版本升级原则 (10)3.2.2.新版本发布 (11)3.3.文档的变更 (12)4.备份管理 (12)1.引言版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理，保证任何时间都可以取到正确的版本以及版本的组合。
版本控制的主要功能是记录开发过程中的每一次修改，让开发的工作可以随时检查过往历史记录和获得正确版本，是系统的成长记录。
1.1.目的本文档的编制是为了规范产品部、研发部、测试部对软件产品版本的管理。
1.2.范围本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关内容，包括：版本标识方法软件系统数据的存放文档的修改控制文档的备份制度1.3.术语定义SCM软件配置管理（Software Configuration Management）缩写SVM软件版本管理（Software Version Management）缩写SVN一个开源的版本控制系统Subversion.文档一种数据媒体和其上所记录的数据。
配置管理标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。
软件配置软件的具体形态在某时刻的瞬时影像。
配置项软件配置管理的对象称为配置项，如：系统规格说明书，项目开发计划，用户手册，源码。
前端UI设计规范制定完善措施
前端UI设计规范制定完善措施前端UI设计规范的制定与完善措施前言随着互联网技术的迅猛发展，用户体验对于网站和应用程序的重要性变得越来越显著。
作为用户接触的第一层面，前端UI设计的规范制定及其完善措施对于提升用户体验、增加用户黏性和品牌形象都起到至关重要的作用。
一、规范制定的重要性前端UI设计规范是指为了确保网站和应用程序的视觉效果、界面布局等方面的一致性而制定的技术标准和设计规范。
规范的制定具有以下重要性：1. 保障用户体验：通过规范化的设计风格、交互操作等，提供一致性和易用性，增强用户体验，使用户能够快速上手并高效操作。
2. 提高开发效率：规范的制定可以统一前端UI设计的原则和要求，在项目开发过程中节省开发人员的设计和开发时间，提高开发效率。
3. 增加产品可维护性：通过统一的规范，可以降低代码的耦合性和维护成本，使前端代码更易于管理和维护。
二、规范制定的过程规范制定应该是一个有迭代、不断完善的过程。
可以按照以下步骤进行规范的制定：1. 调研和分析：了解现有的前端UI设计规范，分析不同的应用场景和需求，并与相关的设计团队、开发团队进行深入交流。
2. 设计原则制定：根据调研和分析的结果，制定一套适用于该项目的前端UI设计原则，包括颜色、字体、排版、按钮样式等方面。
3. 组件库的建设：根据设计原则，制定一套可复用的前端UI组件库，通过组件库的使用，提高设计和开发效率，保证一致性。
4. 版本控制与更新：制定规范后，需要设立规范的版本控制机制，并及时根据用户反馈、团队实践等不断更新完善规范。
三、规范制定应注意的问题1. 兼顾创新与稳定：规范制定应保证稳定性，同时也要兼顾创新，随着技术的发展和用户需求的变化，及时更新规范，保持前端UI设计的活力。
2. 考虑可扩展性：前端UI设计规范需要考虑到项目的可扩展性，保证规范在不同平台和设备上的适配性和可用性。
3. 与设计师密切合作：前端UI设计规范的制定需要与设计师密切合作，及时反馈设计稿的问题和建议，确保规范的实际可行性。
小型开发团队管理套路之创建流程和文档模板
小型研发团队管理流程和文档模板1.文档目的我是从软件开发岗走向软件管理岗的，中间有时候挺迷茫的，期间阅读了一些管理的书籍和博客文章，也接受了管理培训；如今，我在管理的岗位上已经得心应手。
作为一名企业中层管理者，上要让企业高管满意，下要维稳团队，自己还要做一些具体的技术工作，其实中间有很多“套路”可以使用，这篇文章就是把制定流程和文档模板的技巧写下来，给小型研发团队的管理人员借鉴，刚升为小组长的研发管理人员也可以参考。
2.团队背景我如今所在企业是设备制造型企业，所开发软件围绕设备，包含设备标定、设备控制、生产管理等软件；需求主要来源为设备新功能、设备新部件、客户定制需求、售后支持需求等。
与我的小型研发团队相关的人员组织结构如下：图1与研发团队相关的人员组织结构在这样的团队里，经常会遇到的问题如下：我作为软件主管，受软件副总直接管理，但是运营总监对于软件的意见有时候与软件副总相左，这时候我该怎么办？我作为软件主管，团队人员数量有限，需求各种各样，哪个要做哪个不做？哪个先做哪个后做？3.制定流程制定流程是中层管理者要做的很重要的工作，有了流程，上面的领导知道下面的团队是如何运作的，下面的团队知道工作要产出什么东西，上面列的问题通过流程就能解决80%。
我们管理团队讲究的是对事不对人，当有问题发生的时候，应该第一时间思考为什么现有的流程会出现这样的问题，如何改进或建立流程来避免下次发生这样的事情。
制定流程和所有管理一样要使用PCDA环，任何流程都有其优缺点，通过循环改进流程让事情顺利起来，流程贴近团队习惯，减少问题的发生，这样日常80%左右的管理工作都是有序的，只需要很少的精力去关注，大大提高了效率。
要重点说明的是，流程绘制出来后，首先要跟直接领导说明并获得其认可，其次是跟团队人员宣贯并宣布开始执行，最后是开始执行流程时要花时间跟进流程执行情况，主要跟进产出物在正确的时间节点产生并获得确认。
每当有新的成员加入团队时，首先要做的就是让他理解流程，并跟进他前面几次工作任务。
(完整版)软件版本管理办法
广东亿迅科技有限公司软件版本管理办法（暂行）第一章总则第一条为了加强广东亿迅科技有限公司（以下简称“公司”）的软件版本管理工作，进一步细化公司配置管理规范，建立软件版本管理的规范化操作流程，保证公司软件产品质量，制定本办法。
第二条本办法适用于公司各技术部门的软件版本管理工作。
第三条本办法所称的软件版本是指公司所有面向用户发布的应用软件版本。
第四条软件版本（以下简称“版本”）管理应遵循以下原则：(一)实施版本变更应符合以下原则之一：1.为满足客户新业务、新功能需求；2.为满足提高业务质量、提升业务性能指标和容量扩充的需求；3.为解决软件故障和软件稳定性、安全性、可控性问题；4.为了提高软件可维护性。
(二)版本的集成和发布应严格按照计划执行，避免随意和频繁更新版本;(三)为保证软件质量，任何一个软件版本须通过版本测试后方可上线；(四)公司所有软件版本必须通过正式渠道发布给用户，未经审批各部门和个人不得擅自向用户发布软件版本。
第五条版本管理是保障应用软件正常运行的一个重要手段，各相关部门应认真贯彻落实，并纳入工作考核；未按本办法执行从而造成版本故障影响用户正常生产的，一经发现将追究其相应责任。
第二章职责与分工第六条版本管理实行总体质量控制，分级实施管理原则，管理工作涉及版本质量管控部门和版本集成发布部门；质量管理部是版本质量管控部门，各业务部门是版本集成发布部门。
第七条版本质量管控部门的工作职责如下：(一)负责制定与版本管理工作相关的管理办法和工作流程并组织落实；(二)负责组织版本管理相关的培训并提供技术支持；(三)负责跟踪和监督公司版本管理工作的执行情况，协调解决执行中的问题，并对版本管理的执行效果进行评估考核；(四)负责组织和实施对版本的测试验证工作；(五)负责对版本升级实施效果和版本质量进行监控和评估；(六)其它应由版本质量管控部门负责的事项。
第八条版本集成发布部门的工作职责如下：(一)负责本部门版本研发集成工作环境的建立、维护和管理；(二)负责依据版本管理工作流程，执行版本开发、集成、发布及维护的相关工作；(三)负责收集分析业务需求，制定版本计划并按计划组织实施；(四)负责跟踪版本上线后的运行情况，收集用户使用的反馈信息，改进版本质量；(五)其它应由版本集成发布部门负责的事项。
研发规范-版本管理规范
版本管理规范(Version 1.0)XX科技有限公司2014年6月版本管理规范1 目的 (4)2 适用范围 (4)3 版本管理规范 (4)3.1 版本管理工具 (4)3.2 版本库目录结构 (4)3.3 版本命名规范 (5)3.3.1 产品名称 (5)3.3.2 版本号 (5)3.3.3 版本标识 (5)3.4 版本提交规范 (5)1 目的标识、控制和追踪软件开发和实施过程中产生的各种软件产品版本。
2 适用范围适用于研发中心相关项目和产品所有软件文档和源代码版本的管理。
3 版本管理规范3.1 版本管理工具采用Subversion（SVN）进行版本管理。
3.2 版本库目录结构版本库目录结构如下所示：第一层目录为wasu_XXXX(XXXX为项目或产品名称缩写)，每个项目或产品的下层目录结构(第二层目录)如下：trunk 主开发目录branches 分支开发目录release_tags 发布版本存档目录（不允许修改）这三个目录每个目录下层目录结构(第三层目录)统一如下：doc 存放开发过程中的文档src 存放代码一般的，我们的所有的开发都是基于trunk进行开发，当一个版本/release开发告一段落（开发、测试、文档、制作安装程序、打包等）结束后，代码处于冻结状态（人为规定）。
此时应该基于当前冻结的代码库，打tag。
当下一个版本/阶段的开发任务开始，继续在trunk进行开发。
此时，如果发现了上一个已发行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在开发的版本（Developing V ersion）无法满足时间要求，这时候就需要在上一个版本上进行修改了。
应该基于发行版对应的tag，做相应的分支（branch）进行开发。
例如，刚刚发布1.0，正在开发2.0，此时要在1.0的基础上进行bug修正。
按照时间的顺序：1. 1.0开发完毕，代码冻结2.基于已经冻结的trunk，为release1.0打tag此时的目录结构为svn://proj/+trunk/? (freeze)+branches/+release_tags/++tag_release_1.0(copy from trunk)3. 2.0开始开发，trunk此时为2.0的开发版4.发现1.0有bug，需要修改，基于1.0的tag做branch此时的目录结构为svn://proj/+trunk/? ( dev 2.0 )+branches/++branch_dev_1.0_bugfix (copy from tag/release_1.0)+release_tags/++tag_release_1.0(copy from old trunk)5.在1.0 bugfix branch进行1.0 bugfix开发，在trunk进行2.0开发6.在1.0 bugfix 完成之后，基于branch_dev_1.0_bugfix的branch做release等7.根据需要选择性的把branch_dev_1.0_bugfix这个分支merge回trunk（什么时候进行这步操作，要根据具体情况）3.3 版本命名规范3.3.1 产品名称新产品立项时，为产品赋予版本库中的产品名称；当已有产品升级时，则沿用前一版本产品的名称。
企业应用集成之界面集成规范
企业应用集成之界面(U I)集成规范v0.2(总28页)--本页仅作为文档封面，使用时请直接删除即可----内页可以根据需求调整合适字体及大小--企业应用集成之界面（UI）设计规范2015年4月1引言 ................................................................................................................... 错误!未定义书签。
编写目的 ................................................................................................................................错误!未定义书签。
适用范围 ................................................................................................................................错误!未定义书签。
术语定义 ................................................................................................................................错误!未定义书签。
2概述 ................................................................................................................... 错误!未定义书签。
设计原则 ................................................................................................................................错误!未定义书签。
软件项目团队管理：角色、职责与协作
软件项目团队管理软件项目团队管理软件项目团队管理是指在软件项目开发过程中，对项目团队进行计划、组织、协调、控制和评估的一系列活动。
本文将从以下几个方面详细介绍软件项目团队管理的相关内容。
一、项目经理项目经理是软件项目管理的核心，是整个项目的负责人和决策者。
他负责制定项目计划、组织人员、协调资源、控制进度、评估质量等。
一个优秀的项目经理应该具备以下能力：1.领导能力：能够有效地引导项目团队，为项目制定明确的目标和愿景，激发团队成员的积极性和创造性。
2.组织能力：能够合理地安排项目团队的成员和资源，制定清晰的项目计划和工作流程，确保项目各项工作的顺利进行。
3.协调能力：能够有效地协调项目团队成员之间的关系，处理各种矛盾和冲突，保持良好的团队氛围。
4.控制能力：能够及时掌握项目进展情况，发现问题及时纠正，确保项目按时、按质量完成。
5.沟通能力：能够与项目团队成员和客户保持良好的沟通，及时解决问题和反馈，确保项目的顺利进行。
二、系统架构师系统架构师是软件项目的技术负责人，负责整个系统的技术架构和设计。
他应该具备以下能力：1.技术能力：熟悉软件开发的技术和工具，具备深厚的技术功底和经验。
2.分析能力：能够深入分析客户需求和技术需求，为系统设计出符合要求的技术架构。
3.设计能力：能够根据系统需求和目标，设计出合理的技术方案和实施计划。
4.指导能力：能够指导开发人员进行编码和测试等工作，确保系统的实现质量。
5.沟通能力：能够与其他团队成员和客户进行良好的沟通，及时解决问题和反馈。
三、软件工程师软件工程师是软件项目的开发人员，负责软件的编码、测试和优化等工作。
他应该具备以下能力：1.技术能力：熟悉软件开发的技术和工具，具备深厚的技术功底和经验。
2.分析能力：能够深入分析系统需求和设计文档，为软件设计出符合要求的功能和性能。
3.编码能力：能够根据设计文档进行高质量的编码工作，并能够进行及时的代码优化和重构。
4.测试能力：能够制定详细的测试计划和测试用例，进行全面的测试工作，确保软件的质量。
UI设计规范方案说明书模板
UI设计规范说明书修订历史记录日期版本说明作者1前言1.1文档简介本文档是对整个系统界面设计风格进行描述，和用户交互的最终界面在《详细设计说明书》中设计和解释。
1.2系统定义用户界面：又称人机界面，实现用户与计算机之间得通信，以控制计算机或进行用户和计算机之间得数据传送得系统部件。
GUI：即图形用户界面，一种可视化得用户界面，它使用图形界面代替正文界面。
1.3编写目的统一图形界面规范，为开发人员提供统一的标准，为用户提供统一显示效果、统一操作方式的界面，便于用户识别与使用。
2界面设计准则 Rules2.1引言 Introduction在界面设计中应该保持界面的一致性。
一致性既包括使用标准的控件，也指使用相同的信息表现方法，如在字体、风格、颜色、术语、提示信息等方面确保一致。
2.2主要内容 Content2.2.1显示信息一致性原则坚持图形用户界面（GUI）设计原则，界面直观、对用户透明：用户接触软件后对界面上对应的功能一目了然、不需要多少培训就可以方便使用本应用系统。
明确用户是所有处理的核心，不应该有应用程序来决定处理过程，所以用户界面应当由用户来控制应用如何工作、如何响应，而不是由开发者按自己的意愿把操作流程强加给用户。
界面设计必须经过最终确认才能完成。
2.2.2布局合理化原则应注意在一个窗口内部所有控件的布局和信息组织的艺术性，使得用户界面美观。
在一个窗口中按tab键，移动聚焦的顺序不能杂乱无章，tab的顺序是先从上至下，再从左至右。
一屏中首先应输入的和重要信息的控件在tab顺序中应当靠前，位置也应放在窗口上较醒目的位置。
布局力求简洁、有序、易于操作。
2.2.3鼠标与键盘一致性原则尽量遵循可不用鼠标的原则：应用中的功能只用键盘也应当可以完成，即设计的应用中还应加入一些必要的按钮和菜单项。
但是，许多鼠标的操作，如双击、拖动对象等，并不能简单地用键盘来模拟即可实现，此类操作可适当增加操作按钮。
2.2.4向导使用原则对于应用中某些部分的处理流程是固定的，用户必须按照指定的顺序输入操作信息，为了使用户操作得到必要的引用应该使用向导，使用户使用功能时比较轻松明了，但是向导必须用在固定处理流程中，并且处理流程应该不少于3个处理步骤。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2014.5.16
胥冥
工作前提说明
• 设计团队软件&工具
• Adobe PhotoShop （PC&Mac）不解释 • Adobe Illustrator （PC&Mac）不解释
• Sketch 3（Mac）矢量UI 设计工具 （做快速布局方便，逼格高，BUG多）
• Ps Play（iOS&Android）用于手机实时预览PS设计内容 • MarkMan（PC&Mac）设计图标注工具 • TortoiseSVN（PC）Cornerstone（Mac）SVN同步软件
团队 文件整理规范
• 素材管理 • 文档资料 • 软件工具
设计中用到的素材，如UI示例、Icon参考、字体等 设计相关的书籍文档资料等 设计相关的软件工具等
• 识别规范
• 应用资源 • UI 设计 • 运营推广 • 网页设计
公司级VI（logo、名片）设计内容
应用内使用到的附加资源，角色形象，等不适合放在UI设计中的资源 应用UI设计文件，以项目名加版本整理 线上或线下运营推广所需的活动图片设计 公司网站或其他最终结果为网页的设计
• 例（FN-Tech）
• 图片需求规范
• 图片内容：各级文案及相应重要级别 • 图片用途：网页/手机应用/印刷 • 图片属性：宽高尺寸（px像素/mm毫米）、分辨率（ppi：尺寸单位为mm时必需）、格式（PSD/PNG/JPG） • 参考示例：类似场景图片（用于效果预估）、任务方中意图片（用于风格把握）
• 需求备注：需要注意的地方，风格描述，特殊使用限制等
• 参考文档
• 《精准像素完美使用手册》/blog/the-ustwo-pixel-perfect-precision-handbook/ （待学习）
素材管理 文件整理规范
• 子文件夹前缀规范
• [模板] • [示例] 有源文件的整体套用设计方案，可直接使用 有源文件的独立设计方案，可参考部分使用
• 控件子图层/组以所在控件的各个子控件或部件 相应名称命名，规则参照控件，上层组有状态时下属无需状态
• 此命名规则在 层级明确、描述清楚的前提下可适当调整书写，最终目标为仅依靠图层/组 名称即可准确识别内容 • PSD文件避免有空图层、连续未命名图层、未命名组，测试过程中的无用图层及时删除或归档到废弃或测试组
• 子文件夹一级命名：模块名称
• 文件以各自所属模块整理，全局文件视为一个模板单独存放，有子模块内容较多且相对独立时可提高文件夹层级 • 文件夹内页面文件平级放置：PSD(源文件)、JPG(效果图)、PNG(标注图)、mkm(标注源文件)
• 页面文件名：当页面无平级页面且层级较浅时直接用页面名称，否则使用“上级模块-本页名称”
• 例（Btn_TabbarDiyBg v2.1.1.psd） • 版本号（v2.1.1）只用在P控件类型]
参照常用字规范，首字母大写
在保证唯一性与表意明确的前提下可适当放宽书写，如无合适翻译，可用拼音描述
• [位置&功能描述]
• 切图资源文件命名：控件类型_位置&功能描述&部件类型_状态.宽高.后缀
• List（列表）Menu（菜单） • View（视图）Panel（面板）Sheet（薄板：底部弹出菜单） • Bar（栏）StatusBar（状态栏）NaviBar（导航栏）TabBar（标签栏）ToolBar（工具栏） • Switch（切换开关）Slider（滑动器）Radio（单选框）CheckBox（复选框） • Bg（背景：部件）Mask（蒙版/遮罩）
• [收集]
• [参考] • [其他]
有源文件的设计元素，可参考部分使用
无源文件的图片展示，可做设计参考 待完善
• 子文件夹命名：[前缀] 素材类别&内容
• 例：[参考] 手机截屏、[模板] UI套件、[模板] VI展示、[模板] 界面展示、[示例] UI、[收集] 共享图库
运营推广 文件整理规范（待定）
• 例（Btn_TabbarDiyBg_normal.160x98.png） • [控件类型] 参照常用字规范，首字母大写 在保证唯一性与表意明确的前提下可适当放宽书写，如无合适翻译，可用拼音描述
• [位置&功能描述&部件类型]
• 宽高在切图控件尺寸唯一情况下可不写，宽高相等时可省略为标一个数
附录：UI 文件命名规范常用字（初订）
• 子文件夹命名：日期+活动名称+设计内容
• 例（2014-05-12 XX网站推广_Banner）
运营推广 图片需求提交规范（待定）
• 任务需求总概
• 任务名称：简要描述任务或活动主题 • 任务平台：应用市场/微博/线下/第三方应用或网站/
• 任务简介：活动具体实现方案
• 截止时间：图片需求最后截止日期时间
• 常用补充描述
• 上中下排序 Top（顶部）Middle（中间）Bottom（底部） • 次数排序 First（第一）Second（第二）… Last（最后） • 位置排布 Header（页头）Footer（页脚）
UI设计 PSD图层命名规范（待定）
• PSD图层命名
• 依页面框架整理顶层图层组，例：XX-Bar、Sheet_功能描述.宽高 v版本、View_视图描述.宽高 v版本、BG（整体背景） • 子图层组以所在框架内具体控件命名，例：Btn_功能描述_状态.宽高 v版本、bg（所在框架或控件背景）
• 子文件夹二级命名：[切图] [Android]
• [切图] 切图PSD文件平级置于此文件夹下，生成的切图置于PSD同名文件夹下
• [Android] 以iOS为主导时，Android平台适配版本置于此文件夹下，管理规则同iOS （独立时可提高层级）
UI设计 文件命名规范
• 切图PSD文件命名：控件类型_位置&功能描述 v版本.后缀
• 常用状态
• normal（正常）pressed（按下）selected（选中）disabled（禁用）visited（已访问）hover（悬停）
• 控件&部件（控件：较独立的可操作界面元素）（部件：描述属于某控件一部分）
• Btn（按钮：可点）Icon（图标：不可点、非点击主体、图案部件） Sign（标记）
• 插件补充
• PS：Rounded_Rectangle_Radius_Resizer（矩形圆角半径调节）方便，稳定，四个角 • PS：Corner Editor（多边形圆角半径调节）支持多边形，多种角，不稳定，BUG较多
• PS：GuideGuide （辅助线插件）支持设置数值、分栏等，可存预设
• PS：Kuler（色板插件）辅助配色方案，可搜索、自定
• 可用素材：可以使用于设计中的人物元素等素材，附件发送
识别规范 文件整理规范（待定）
• 子文件夹命名：品牌(公司/应用) 设计内容 v定版版号
• 例（喵喵 Logo v2）
应用资源 文件整理规范（待定）
• 子文件夹命名：资源名称
• 待定
网页设计 文件整理规范（待定）
• 主文件夹命名：WEB
• 子文件夹一级命名：网站(网页)名称
UI设计 文件整理规范
• 主文件夹命名：应用名称 版本号&增量标记
• 例（喵喵 2.0）（喵喵 2.1+） • 版本后无+为完整版本，带+为增量版本，增量版本只保存对前一个完整版本有修改的内容
• 版本号（例2.1.1）首位变化新建完整版本，二位变化新建增量版本，第三位变化时仅新建修改版本文件
• 新建完整版本（2.0）时，先前的完整版本及其增量版本可进行首位归档，及（喵喵 1.0、喵喵 1.1+）归入（喵喵 1）中 • 首位归档文件夹达到3个后可进行项目归档，即（喵喵 1、喵喵 2、喵喵 3）归入（喵喵）中，后续依次添加 • 版本归档操作由组长执行