部门制度软件开发部管理条例.docx
《部门制度软件开发部管理条例.docx》由会员分享，可在线阅读，更多相关《部门制度软件开发部管理条例.docx（23页珍藏版）》请在冰豆网上搜索。
部门制度软件开发部管理条例
文档编号：
UR001
文件状态：
[]草稿
[√]正式发布
[]正在修改
当前版本：
V1.0
制作人：
签发人：
发布日期：
软件开发管理条例
合肥甬信功信息技术有限公司
版本信息
版本
作者
修改日期
更新内容
备注
0.8
江文
2010-06
创建
0.9
江文
2012-07
陆续修改了各个章节
一、术语定义
1.处罚获得的资金作为本部门内部奖励、活动的资金。
2.次数处罚：
按次数进行处罚，后面的数字为处罚的金额，如【次数处罚50】表示每次处罚50元。
3.区间处罚：
视具体情况处罚一定区间内的金额，如【区间处罚50-100】即视具体情况处罚50-100元。
4.累计处罚：
累计到一定次数后会被处罚，如【累计处罚7/50】表示累计达七次处罚50元。
5.编程规范处罚：
未按规范进行编程的，视情况处于50-300元的处罚。
6.其它处罚：
文档少一份罚100元，单据少一份罚20元。
二、文件命名规范
1.项目备份文件夹格式“项目备份_误删”
Ø同时存放在两个不同磁盘分区的根目录下
Ø两个项目备份文件夹下的文件要保持同步，完全一致
2.项目文件夹格式[项目英文名称][项目中文名称]
Ø如“ltcl联通材料项目管理系统”
3.项目资料文件名称格式“文件名称_[提供人姓名]_[提供日期]”
Ø如“管线系统问题汇总（7.30）_胡冲达_2012_07_31.docx”
Ø包括客户提供、同事间传阅等
4.生产性文件名称格式“[备份人姓名]_[项目英文名称][项目中文名称]_[文件类型]_[备份日期]”
Ø如“梁腾达_jhlkxyk_龙卡信用卡企业服务平台_数据物理模型_2012_06_01.PDM”
5.区间文件名称格式，在上述两种文件名称的基础上使用双日期
Ø如“江文_ltcl联通材料管理系统_源代码备份_2012-7-15_2012-7-31.rar”备份，表示2012-7-15到2012-7-31源代码备份是同一个文件。
三、条例概述
1.客户单据：
单据要明确、清楚的阐述其内容。
从用户理解的角度解释功能的实现，包括用户操作方式、操作界面、信息展示方式、关键描述等视觉、动作、描述信息。
根据标准单据的格式相关人员依次签字确认，如果客户对内容进行较多修改要重新开单，直至用户未修改或少量修改了单据内容为止。
单据没有最终确定之前不能进行相应内容的开发。
2.签字流程：
Ø准备简要事务内容说明，用户操作复杂、有技术难度、当前技术不可实现的要特别说明。
Ø当事项目经理、部门经理、销售部经理商定用户需求，由销售部经理确定哪些需求要开发，哪些需求不要开发。
Ø单据中有明确签字位置的相关人员都要签字；项目组成员根据实际的相关情况签字，如程序员、美工。
Ø单据由提交方回收、存档，其它部门保留复印件。
3.文档样式：
Ø文档名称为：
姓名_项目英文名称_项目中文名称_文档名称_最后修改日期,如“江文_UNITECH_优创项目_管理条例_2010_09_11.doc”。
【次数处罚10】
Ø文档的内容依次为封面、文档控制页、目录、正文。
Ø正文：
宋体、小四号、1.5倍行距、首行缩进两个中文字符。
Ø标题：
使用WORD一、二、三、四级标题。
标题必需在文档结构图中显示。
Ø奇数页页眉左边为文档名称，右边为公司标志；偶数页页面左边为公司标志，右边为文档名称。
Ø页脚中间显示页数，格式为“第1页共10页”，目录后的正文第一页页码为1。
Ø样本格式文档中：
黑色正文表示实例，灰色正文表示对相应内容的描述。
4.图形
Ø图形使用专业的工具书画，如VISIO、POWERDESIGN、亿图图示专家，Excel。
Ø图形直接原图拷贝到ＷＯＲＤ，不行时截图。
Ø文字、图形大小合适，能被清楚的查看，居中放置。
5.方案、标书、美工风格、首页在给客户前要给部门经理查阅
四、事务处理流程
1.工作安排：
有新的工作任务时最迟于次日完成工作任务或对工作任务做出具体的安排。
2.内部工作安排通报：
将工作安排以书面签字的方式通报本部门主管、营销对接人员，签字不方便时以邮件形式发送；本部门内部开发开工单不向营销对接人员通报。
3.内部完成确认：
本部门主管现场检查、签字确认工作完成情况（在原签字处填写确认、日期字样）。
4.外部完成确认：
当工作内容与外部客户有关时，需向客户方负责人通报工作完成情况，需要客户方进行配合验证工作完成情况而客户方未能有效配合的第一时间通报本部门主管、营销对接人员。
五、项目开发流程
1.项目开发流程依次为需求分析、前期设计、开发编码、项目测试、项目部署、书写文档、项目验收。
2.需求分析：
书写需求规格说明书、概要设计说明书。
Ø需求规格说明书、概要设计说明书一式两份，公司一份、客户一份。
Ø需求规格说明书要求签字、盖章；概要设计说明书要求签字。
3.前期设计：
书写详细设计说明书、业务逻辑模型、物理数据模型、页面设计、进度人员安排。
Ø出美工风格的项目确认单。
Ø出系统的页面演示模型。
Ø出项目开工单，即开发的总体时间安排，不包含具体的实现细节，未确定的功能特别声明且不计时间；。
4.开发编码：
在公司公共代码的基础上，根据编程规范开发，需求变更时同步更新相应文档。
Ø功能开发时出开发开工单，包含实现细节（如用户界面），内容较多时分模块、分批次出单。
此阶段要和客户进行充分的沟通，确定最终的内容、实现方式，用户不满意时要重新设计，直至用户满意。
复杂模块项目经理或项目负责人要预先设计实现的方式。
Ø功能编码完成后由项目负责人或项目经理及时验证功能的实现是否符合需求、技术实现是否合理。
Ø进行项目功能确认。
Ø客户确认后及时交叉验证功能实现是否存在BUG。
Ø功能交叉验证后，由开发人员书写功能的详细设计说明书。
Ø需求变更时出修改单。
需求变更、增加影响到项目进度时出项目开工单修正。
Ø客户临时性的费时较少、功能变动小的需求可不出开工、修改单直接开发，开发完后及时出项目确认单让用户核对确认。
Ø需求开发完成测试之前，项目所有的功能都要得到用户的确认。
Ø使用项目冗余时间时提交项目延时报告。
Ø必要时可以变更单据中客户的签字顺序，便于实际操作。
5.项目测试：
开发小组自身白盒测试，然后出测试单、回归测试单测试，直至回归测试完成。
6.项目部署：
出部署单部署软件（任何时间、任何地点、任何情况没有完整签字的项目部署单不能将程序部署到客户服务器上），写部署日志，进行软件运行监测。
7.书写文档：
书写用户手册、数据库设计说明书、系统安装手册、项目总结报告、验收总结说明（验收会议用）、验收演示PPT、重新修订需求规格说明书并签字盖章。
整理、装订项目文档。
在项目验收前两天完成上述工作。
8.项目验收：
验收前一天和客户协调好验收的内容、方式，配合客户完成验收工作。
9.异常处理：
Ø备忘说明：
项目的单个事务久拖不决满三周后出项目事务备忘录，一个项目事务备忘录中包含该项目当前所有久拖未决事务、重要事务。
Ø项目运行时出现异常时要出异常报告，陈述清楚异常情况、处理方式、处理结果。
六、进度控制规范
1.部门经理及以下人员的所有工作必须有单据，下列情形除外：
Ø部门经理的日常监管工作
2.未能按单据上确定的时间完成工作任务的，可选项如下：
Ø加班自行消化
Ø出项目延时单
七、项目维护流程
1.项目维护区间非客户原因的程序修改出项目维护单。
八、标书规范
I．结构图、拓扑图、用例图、数据流等系统概述条目
Ø使用图形方式表述。
Ø图形占据一个整页；
Ø逻辑清晰（只表述核心、必要内容），内容简练、饱满（内容过少时表现得细节一些，内容过多时分画面或概述），用户一眼就能直观的了解具体的内容。
II．模块设计
Ø使用图、文结合的方式表述。
Ø模块结构图表述模块的结构、运行方式等信息，根据模块的特点从不同的角度表述。
Ø功能图形表述功能的展示、操作界面，内容要准确。
Ø文字说明的包括内容描述、系统及模块层的意义、优缺点、实现方式、操作方式
Ø文字说明不能少于三行且一百字以上；尽量在六行以上，保证内容的饱满。
九、需求规格说明书规范
1．编码前需求规格说明书要打印、签字、盖章；项目结束后根据需求的变化修订需求规格说明书，然后重新打印、签字、盖章。
2．需求分析的特点。
Ø它们必须是正确的。
Ø它们必须是可行的。
Ø它们必须是对项目来说必不可少的。
Ø它们必须是被标明优先顺序的。
Ø它们必须是不含糊的。
Ø它们必须是被证实的。
3．客户说的有时候是手段，不要忘记了客户的最终目的。
4．需求分析的准备：
了解客户的业务，了解客户的组织结构，了解客户所在的行业规范，了解行业内同类的产品及其解决方案，让自己具备和客户讨论业务的能力，让客户信任团队；了解软件的决定权在谁手上，了解是谁使用软件，和上述人员搞好关系，便于协调需求。
5．需求的访谈：
从软件使用者使用软件的工作目标来明确方向。
注意用户的使用习惯，风格，操作系统（这和用户经常使用的软件相关），最好看些相关书籍。
6．需求分析的模版：
用专业的模版，给用户专业的感觉，表面的工夫要做足。
7．需求分析的注意点：
确定系统主要的大部分的数据库字段信息。
8．功能需求按“用户操作>>系统处理>>系统响应”模式书写。
9．使用DOORS书写需求规格说明书。
10．未使用DOORS书写需求视缺失的数量罚款50到500元。
十、物理数据模型规范
1．使用Powerdesign管理物理数据模型。
2．名称：
Powerdesign中表格基本信息、字段基本信息中的name。
3．代码：
Powerdesign中表格基本信息、字段基本信息中的code。
4．数据库编码统一使用UTF-8字符集。
5．表格
Ø名称为中文名称，代码为英文名称（中文拼音首字母及下划线）。
Ø英文名称为使用下划线作为分隔符号的层次结构。
Ø层次结构按系统（多系统共用一个数据库）、模块划分，逐一延伸，如目录分类信息MENU_SPLIT。
Ø模块连接表使用各模块的关键层次名称混合做前缀，如目录_报表与日期方案字典库MENU_STATISTICS_DATE。
6．字段
Ø名称、代码都使用字段实际名称（中文拼音首字母及下划线）
Ø字段名称为中文拼音首字母、下划线组合；多个单词间使用下划线隔开。
Ø每个字段都要有中文注释（ID字段除外）。
Ø字段的排列顺序为主键、外键、其它。
Ø表格必需有一个唯一性限制、整型数字、名称为ID的字段；遗留表格除外。
Ø严禁使用固定长度字符字段CHAR。
7．主键
ØID字段为主键，除非是必须使用非递增数值作为主键、遗留表格。
Ø使用ORACLE数据库时，建立一个名称为“SEQ_表格名称”的序列来填充ID字段的值；MYSQL或SQLSERVER数据库时将ID字段设置为自动增长类型。
8．外键
Ø强制外键显式的使用折线关联、明确关联字段、级联删除特性。
Ø非强制外健（可能是、可能不是）使用连接线表示。
Ø能使用强制外健时不能使用非强制外健。
9．布局
Ø表之间尽量保持竖向、横向上的对齐
Ø相关联的表格放置在相邻的位置
Ø无外键的表格整齐排列在模型的上方。
Ø外键连线尽量不要交叉。
10．【区间处罚50-100】
十一、业务逻辑模型规范
1．使用Powerdesign管理业务逻辑模型。
2．业务逻辑模型必须符合UML标准。
十二、详细设计说明书规范
1．使用DOORS管理详细设计说明书。
2．专业术语：
定义在当前项目中使用的特有的术语，避免在技术手册中重复出现。
确实多次重复出现的内容相同的整体描述可以定义为专业术语；内容有差异多次重复出现的类似描述不能定义为专业术语；十分简单的描述不能定义为专业术语。
专业术语使用深红色标记。
3．功能列表：
列出用户需求中的功能列表，处理方式表示该需求功能具体在哪一个代码块中实现，防止技术手册中的开发描述部分遗漏用户的需求。
4．功能描述：
I．数据输入：
用户的数据输入、操作命令。
数据输入太多时可以只列出关键的几个。
操作命令的格式如用户删除命令。
II．数据处理：
描述业务处理逻辑及相应的数据库操作，描述语言要求清晰、简练、具体、确定。
描述的原则是能让程序员通过阅读技术手册能明白该做些什么，该怎么去做，不用告诉程序员该怎么去写代码。
Ø使用条目名称：
条目内容的方式书写。
条目名称使用橙色。
条目内容使用黑色。
Ø原则上一个条目描述一个完整的数据处理过程或用户操作，当该条目的内容过多时可以进行分割。
Ø条目的内容包括业务逻辑的处理过程及对应的数据库操作。
Ø业务逻辑的描述要用词简练，内容具体、确定（不能使用可以、可能等选择性、模糊性词语），常识性的内容不用描述或简单掠过。
复杂的用文字不便描述的业务逻辑不在说明中书写，直接书写一个对业务逻辑模型的引用即可。
说明书中不包含对页面布局的描述，直接书写对页面设计的引用即可。
Ø数据库操作的描述要显式的指明表格名称、字段名称（非外健联合查询、确定的条件查询如只显示审核过的数据等、枚举子段的赋值），表格名称、字段名称出现时要同时连续书写中英文名称（名称要和物理数据模型一致）。
数据的删除要显示的区分删除、级联删除。
Ø说明书中不包含对代码实现的描述。
Ø描述中“和”尽量使用顿号代替，尽量使用分号等标点符号让描述的条理更清晰。
文字较多时，良好的标点符号应用能极大的提高可读性。
Ø同一数据的修改、增加操作视为同一个条目，统一写成数据增加条目。
Ø使用绿色字体引用公司代码库中的功能模块的实现。
Ø使用红色字体引用当前项目中其它功能模块的描述。
引用时要显式的说明引用的模块名称、条目名称。
Ø开发人员在开发过程中发现修改说明书中的内容描述不正确时，要和项目设计人员进行核对，并对相应的内容进行修改，使用蓝色字体标记出修改过的内容。
每周一将修改过的内容同步到最新的项目说明书中。
III．数据输出：
书写描述用户操作的结果。
IV．【区间处罚50-100】
十三、页面设计规范
1.使用标准的美工模版设计页面。
2.页面设计要包含完整的布局信息，开发人员根据页面设计能依样实现相应的页面。
3.页面设计不用实现脚本、代码。
动态展示的界面只需在页面的下方分标题列出即可。
4.页面使用英文名称，格式为模块名_子模块名_类型标志。
子模块名可以有零或多个，如porject_document_page_edit.html（项目_文档_页面_修改）。
5.当前项目的所有的功能都要有相应的页面设计。
十四、项目时间估算
1．项目时间估算的内容包括：
Ø前期设计（需求规格说明书【包括需求沟通及后期修订】、概要设计说明、详细设计说明、物理数据模型、业务逻辑模型、页面设计）【包括打印装订】
Ø美工设计（由美工估算）
Ø材料处理（如纸样转换为文字、图片、矢量图等）
Ø功能细分（新增、修改、删除、查看、查询、汇总、导入、导出、打印等）
Ø模块分类（登录、登录退出、系统主界面、数据交换、数据备份、数据接口、扩展接口等）
Ø项目测试修改（美工设计、功能开发时间的百分之十，最少一个工作日）
Ø系统数据初始化（用户及权限设置、系统基础数据录入、当前业务数据导入、历史业务数据导入、外部数据导入）
Ø项目部署实施（可能的多点部署）、监测（程序部署、部署日志、系统监测）
Ø书写用户文档（用户操作手册、系统安装手册、项目总结报告、数据库设计说明书）【包括打印装订】
Ø用户培训（确切了解用户培训要求）
Ø中途演示、沟通时间预估（开发周期区间周数×0.5,最少三个工作日）
Ø项目验收（验收演示PPT、验收会议）
Ø项目管理（开发周期区间周数×0.3，最少三个工作日）
Ø上述时间百分之二十的为功能调整预留（即冗余）
Ø上述时间百分之十的为项目维护预留（即维护）
2．不论内容、时间先后，凡是在项目开发中要花费时间的条目都要计时。
3．【区间处罚50-100】
十五、项目进度规范
1
十六、项目测试规范
一、测试单按项目的重要性、迫切性划分等级
一级：
立即测试
二级：
优先安排测试
三级：
可适当延迟测试
二、回归测试单用词解释
总缺陷：
测试部门测试出来的缺陷总数
已修改：
确实存在的缺陷且已经修改的数目
非缺陷：
测试部门登记的缺陷而程序员认为不是缺陷，经和测试人员沟通确认确实不是缺陷的数目；注意非缺陷的决定权在测试部门，程序员有保留意见时写在相关单据的备注中。
重复缺陷：
登记内容的缺陷个数，A与B重复计一个重复缺陷。
不明缺陷：
测试部门登记的缺陷而程序员无法理解且测试部门没有合理解释的缺陷数目。
十七、项目部署规范
1．给客户部署的功能都必须是实现的、已经测试的代码。
未实现的功能不要在客户部署中出现，或者用“正在建设”之类的提示代替。
2．将用户部署前的数据库、程序运行文件拷贝回公司备份。
3．维护项目的部署日志，无特殊情况时，部署日志中的所有信息必须填写完整。
4．重新启动客户的硬件服务器时一定要事先得到客户的同意。
5．有条件时使用GHOST软件备份服务器系统。
6．数据库用户名六位以上字符，密码八位以上的字母数字相结合的字符。
7．项目监测：
项目部署后要监测项目运行情况。
外网程序一天监测两次，政府内网程序一天监测一次；监测内容包括，系统是否运行正常、稳定。
监测满两周且最后连续7个工作日无异常后结束监测，反之时间顺延。
8．【区间处罚50-100】
十八、用户手册规范
1．用户手册的核心内容包括：
业务流程图、功能操作说明。
2．业务流程图
Ø核心业务流程图，放在手册的首部。
Ø复杂模块的业务流程图，放在模块的首部。
3．功能操作说明
Ø使用画面截图与文字说明相结合的方式表述；
Ø截图尺寸适当，用户能清楚的观察；
Ø文字说明包括
Ø功能介绍
Ø操作限制说明（如表单输入限制，文件上传的类型限制，数据导入的格式限制）
Ø特殊操作说明（如表单的关联显式说明）
Ø功能操作说明（如增加、修改、删除、保存、上传、计算等，按操作分条目说明）。
使用“用户操作>>系统响应”的模式书写。
4．【区间处罚50-100】
十九、人员管理规范
1．人员外派，外派人员调动时要和通知销售部门，由销售部门和客户协商具体的人员流动事宜。
2．【区间处罚50-100】
二十、项目文档适用情况
1．项目文档包括：
实施方案、需求规格说明书、概要设计说明书、详细设计说明书、物理数据模型、数据库设计说明、业务逻辑模型、用户手册、系统安装手册、开发总结报告、测试总结报告、项目进度、项目部署日志。
2．项目单据包括：
项目开工单、项目开发开工单、项目修改单、项目确认单、项目事务备忘录、项目延时报告、软件验收报告、项目部署单、项目测试单、项目回归测试单、项目事故报告。
Ø单据未在合理的时间范围内提交签字的，一张单据罚款50元，罚款金额累加，不能及时制作单据的要事先报告。
3．客户验收的项目文档：
Ø需要打印装订：
需求规格说明书、概要设计说明书、详细设计说明书、数据库设计说明、用户手册、系统安装手册、开发总结报告、测试总结报告。
Ø不需要打印装订：
业务逻辑模型、物理数据模型。
4．部门验收的项目文档：
需求规格说明书、详细设计说明书、业务逻辑模型、物理数据模型、数据库设计说明、用户手册、系统安装手册。
5．移交给客户的材料：
【实施方案】、需求规格说明书、概要设计说明书、开发总结报告、测试总结报告、用户手册、系统安装手册、项目部署日志、程序部署文件、数据库备份、应用程序环境（应用程序服务器、JDK等）；合同中声明客户拥有源代码的情况下还包括：
源代码、物理数据模型、数据库设计说明书。
二十一、即时备份规范
1．即时备份文件包括
Ø客户资料文件
Ø同事传阅文件
Ø自身修改过的项目文件
二十二、每周备份规范
2．已开工未做最终备份、维护修改中未做最终备份的项目要每周备份。
3．每周一上午十点半之前项目负责人将项目文件放到指定位置上（暂为192．168．1．252上包含当前日期的每周刻盘共享文件夹下），外派人员将文件传回公司。
4．备份的内容包括
Ø项目清单，
Ø各个项目的源代码、数据库、项目进度、实施方案、需求规格说明书、概要设计说明书、详细设计说明书、业务逻辑模型、物理数据模型、页面设计、测试报告、项目部署日志、项目事务备忘录、用户手册、开发总结报告、系统安装手册。
5．同一项目的备份文件前缀相同，文档放在备份文件夹的根目录下，一个文档包含多个文件时打包为压缩格式。
6．项目已结束或阶段性结束且连续两周没有变更需求时做最终备份，最终备份放在备份文件夹的子文件夹中，子文件夹的名称为“项目英文名称_项目中文名称_日期”。
每周一个项目未及时有效备份的罚款50元，罚款金额累加。
二十三、最终备份规范
1．项目结束时项目组成员提交最终备份单及相关纸样、附件。
2．部门经理审核最终备份材料并刻盘备份，一式两份，部门存放一份、技术总监处存放一份。
最终备份命名规则：
BAK项目管理软件登记编号_项目英文名称_项目中文名称_最终备份日期。
其中灰色表示名称参数，项目管理软件等级编号即为Redmine中的项目登记编号。
二十四、项目文件存储
1.任何备份文件都一式两份，存放到两个不同的硬盘分区中，除特殊声明外。
2.项目文件存放在三处
Ø和应用程序关联的直接文件
Ø[本地磁盘X]＼项目备份_误删＼[项目文件夹]，简称本地存储
Ø192.168.1.254＼软件项目—文件备份＼[项目文件夹]，简称NAS存储
3.未更新但需要备份的文件使用区间文件的方式重命名处理。
4.项目资料（客户提供）
Ø即时本地存储
Ø即时NAS存储。
5.生产性文件（员工制作）
Ø每天本地存储（有更新时）
Ø每周NAS存储（不论有无更新）
6.大文件存储（请及时上报不适于多版本存储的文件）
Ø在一个备份位置同一个文件只有一个版本
Ø适用的文件格式包括：
二十五、日志规范
1．任务分类
Ø项目工作：
项目相关的所有事务。
Ø基础性工作：
为日后的工作提供软硬支持，改善工作环境。
如规范制定、第三方知识学习、公共的技术支持等，登记在“基础性工作”项目中，一件事情一个任务。
基础性的工作完成后要有相应的成果作为公司的技术积累。
Ø培训：
提高个人的业务能力。
Ø杂务：
上述之外的工作，登记在在“杂务”项目中，在杂务项目中每个员工只有一个任务，任务名称为“员工名称杂务”，如“江文杂务”。
2．任务条目
Ø任务条目的必须正确填写的内容包括：
编号、主题、描述、状态、指派给、预期时间、完成度。
Ø每一个项目任务有一个唯一的编号：
[项目编号]_[任务编号]，任务编号从001开始，顺序递增。
Ø有单据、即将出单据的项目任务可以登记为日志任务，单据的任务条目与日志的任务条目相同。
Ø同一模块或功能的多次修改或变更有相应单据的则新建起始任务的子任务，任务名称为起始任务名称加上修改描述，如“工作台—信息确认”。
Ø一次测试后的修改为一个独立的日志任务，任务名称为系统测试修改或回归测试修改加上测试单号，如“系统测试修改P001”，“回归测试修改P402”。
Ø与客户沟通、项目会议、项目验收等临时性客户相关的工作可以新建任务。
Ø非上述三种情况不能新建对应的日志任务。
Ø任务条目的颗粒度应让观察者能简单的将条目、时间花费对应起来，即观察者不需要在将时间细分，不需要将任务细分。
时间花费在3个工作日之下且内容在现实的通
升级会员 