文档库 最新最全的文档下载
当前位置:文档库 › 前端开发手册文档讲解

前端开发手册文档讲解

前端开发手册文档讲解
前端开发手册文档讲解

手机前端入门实例快速开发指南

1文档管理

1.1 文档信息

文档名称手机前端入门实例开发指南

保密级别文档版本编号

制作人制作日期

复审人复审日期

1.2 修改记录

时间版本说明修改人

2内容摘要

新手入门参考文档,辅助入门。

3目的

熟悉并掌握

●前端的开发流程

●前端的开发规范

●通过做简单的示例完成页面流程的开发

4前提条件

前端开发都是基于jquery进行开发,引入js时要先引入jquery.js文件.

4.1 软件环境

1、开发环境:eclipse

5开发规范

一、目录结构

1、H5页面文件目录位于www/views目录下,针对不同功能模块,建立不同的子目录。JS文件位于www/js/controllers目录下,与页面相同,不同的模块建立不同的子目录。如以下例子:

www/views/demo/demo.html

www/js/controllers/demo/demo.js

二、文件名要求

文件名以小写开头,取有意义的英文名字,H5文件名与对应的JS文件名相同。

三、文件格式

UTF-8格式

四、页面中id命名要求

除入口页外,一个页面就是一个Page,每个Page有唯一ID,该ID命名以文件名开头,以View结尾,如demoView

页面中包含的链接,button,其ID以Btn结尾,如loginViewBtn

五、H5内容要求

页面类型模块功能入口页以及子页面

功能模块的入口页,需要包含基本类库,以及入口页对应的JS脚本,其他子页面只有一个Page内容

页面只有html内容,无任何Javascript脚本。

对没有任何业务逻辑控制的页面,可以href的方式直接跳转

对于有业务逻辑控制的页面,应绑定链接事件方式,在事件中需要显示loading 层,转到目标页面后,再隐藏loading层。(未实现原生loading显示)

页头页尾固定在head添加如下属性

data-position="fixed" data-tap-toggle="false"

六、JS内容要求

以匿名函数创建并执行的方式新建JS脚本

(function(){

//业务逻辑在此添加

})();

业务逻辑需要实现以下:

在pageinit方法中初始化页面元素的绑定事件,页面数据的预加载,如:验证码,账号列表

$("#loginView").live("pageinit", function(){

$("#logonBtn").on("click", login);

}

------------------------------------------------------------------- 对于动态生成的数据:

select下拉框,如果需要从服务器获取数据,则通过

$.mbank.pajax("queryMyEquation.do",formData1,forBalance);方法获取,并在定义forBalance方法处理返回结果,

processResponse: function(data) {

var aList = data.aList;

$.each(aList, function() {

$('

'').appendTo('#aSelect');

});

}

对于listview,动态生成后,需要调用listview("refresh")

----------------------------------------------------------------- Init.js中配置手机server的地址以及在开发模式设置var devMode = true;

在手机server端生产模式修改Constans.property XXX属性为false

七、关于字典数据

业务系统用到的字典数据在需要反显名称的清空下,可在mbank.utils.js定义获取名称的方法,如getSexName

在需要的地方调用:

$("#sex_name").text($.mbank.utils.getSexName($.mbank.context.sex)); 少数数据可在select下直接添加,另外可在数据字典dataDict.js添加数据Mbank.utils.js中有公共的方法,如果功能需要可以调用,方法描述请看js文件

八、关于$mbank.core

可获取当前登录会话信息:$.mbank.customer

获取上下文提交的数据:$.mbank.context.loginName

保存表单数据:$.mbank.saveFormData(当前页调用)

填充表单数据:$.mbank.setFormData(下一页调用)

页面导航:$.mbank.goPage

提交请求到服务端:$.mbank.pajax

九、关于调用原生方法

调用原生的js方法写在mbank.core.js文件里,js调用原生是通过cordova的插件实现的,但是这一步已经经过封装,我们只需要知道如何调用就OK,例如关

闭webview这个动作需要js去操作原生现在就只需要用:$.mbank.closeWindow() 页面显示或隐藏loading层:$.mbank.showLoading/hideLoading/isLoading()

调用原生的提示框:$.mbank.closeWindow()

十、关于原生插件

以android为例简述插件调用的原理

/mobileApp/platforms/android/res/xml/config.xml这个目录的文件和

/mobileApp/config.xml这一文件保持一致是js调用原生的基础.

在/mobileApp/platforms/android/assets/www/cordova_plugins.js这个文件汇总了所有的插件,标明了js方法和java类的对应关系,通过这个文件找到相应的js文件.

如:/mobileApp/platforms/android/assets/www/plugins/com.yuchengtech.mo bileapp.plugins/www/progress.js这个文件中的方法定义了调用原生需要操

作的回调函数以及传递给原生的参数.

再根据配置的java类路径调用原生.

十一、开发流程

1、定义页面跳转流程。(注意,1个页面中包含多个js脚本,需要都包含在controller中,否则无法初始化)

2、新建H5页面

3、新建对应JS脚本

备注:个人认为混合开发大部分功能性交易都是H5做的,应该遵循这样一种开发流程:

1,UED部门出设计行方确认通过

2,美工依据设计完成全局CSS的编写

3,H5开发人员依据开发规范套用CSS进行开发

4,搭建手机server环境,init.js修改为手机server地址进行接口调试

6入门实例

6.1 实例一:HelloWorld

1、创建如下工程目录视图

工程划分为业务层面的控制层和显示层.views文件夹用于存放html文件,views中的每一个文件夹对应一个业务功能,每一个业务功能有一个入口页面,入口页面引入了全部的js文件和css文件.如下图所示:

一个功能对应的html:

入口页需要引入相应的js文件和css文件,其他非入口页只需要是一个page容器不需要引入js和css

Common文件夹存放了公共的js文件

2、页面初始化方法

一个功能页相对应的js文件,其中demo.js是入口页,需要注意的是入口页初始化方法需要使用:

(function(){

$(document).ready(function(){

//入口页面初始化需要进行的操作

});

})();

非入口页如login.js使用如下方法:

(function(){

$("#页面pageId").live("pageinit", function(){ //非入口页面初始化需要进行的操作

});

})();

Controllers文件夹存放了控制view的js代码,mbank.action.cfg这个文件指定控制关

系和加载顺序.

View这个文件夹存放了html页面资源,和controller中的js是一一对应的,方便维护

3、完成helloworld

3.1 创建html

在view文件夹下创建demo和demo.html,文件夹名字和文件名保持一致

jQuery Mobile Web

Mobile 演示2

底部

3.2 配置mabnk.action.cfg

在mabnk.action.cfg中指定关系,如上图.

3.3 完成配置的js

在controllers中创建demo文件夹和demo.js文件.

(function(){

$(document).ready(function(){

$("#loginViewBtn").on("click",showLoginPage);

$("#registViewBtn").on("click", showRegistPage);

});

function showLoginPage(){

$.mbank.showLoading();

$.mbank.goPage('demo/login.html');

};

function showRegistPage(){

$('#registView').remove();//清除缓存

$.mbank.showLoading();

$.mbank.goPage('demo/regist.html');

};

})();

4、实际操作用得到的方法

3,如果要发送请求,请求数据并且拼接在dom中,拼接的对象还有后续的事件就这样写:

(function(){

$.mbank.pajax("queryMyEquation.do",formData1,forBalance);

function forBalance(data){

console.log(data);

var balance=$('

可用余额
’+

'+data.avlBal+'
');

$("#balance").append(balance);

$("#balance").css("display","block");

}

})();

绑定到动态拼接的dom上的事件方法需要写在匿名函数外层,否则找不到

Function other(){//做一些事情};

4,如果是动态下拉框,就使用如下写法:

select下拉框,如果需要从服务器获取数据,则通过

$.mbank.pajax("queryMyEquation.do",formData1,forBalance);方法获取,并在定

义forBalance方法处理返回结果,

}

Function forBalance(data){

//格式化返回数据为json

data=JSON.parse(data);

$.each(data,function(index, element) {

//遍历数据动态拼接option 添加到select元素

$('').appendTo("#crditNo");

//刷新select重新渲染

$("#crditNo").selectmenu( "refresh" );

});

};

对于listview,动态生成后,需要调用listview("refresh");

软件项目集成开发流程及文档

软件项目集成开发 一、项目组织架构 A 项目经理 负责分析、设计和协调工作。随时监控各开发人员的工作,包括内容是否与要求发生偏差,进度是否滞后等等,同时给每个开发人员明确的任务书。 在项目周期内项目经理最好不要更换。大项目需要配备专门的系统分析师和系统设计师。 B 开发人员 熟悉针对软件开发的编程工具,并具有丰富的编程经验,负责完成不同层与模块的编程工作。 开发人员数量视系统模块数量和开发难度而定。 C 业务需求人员 熟悉业务工作流程,有丰富的业务经验。 业务需求人员的选择应覆盖系统所服务的业务部门。 D 文档整理人员 随时整理系统开发过程中相关的技术文档。 作为业务支撑,文档整理人员需熟悉软件开发的流程、文档管理、文档模板。 项目组织架构 项目经理 开发人员 业务需求人员 文档整理人员 测试工程师

E测试工程师 专门进行代码的测试工作,并且计划和执行源代码复审,负责有关返工的任何反馈意见(有条件可配置)。

二、项目流程管理 系统开发的过程必须符合IT 项目开发流程的规律,整个过程应包含但不仅限于以下环节: 需求调研是软件开发的最初阶段。需求调研的结果确立了软件开发的方向。软件设计是后续开发步骤及软件维护工作的基础。 在项目实施的过程中,项目实施者大多把精力放在了编码阶段,而需求调研和系统设计往往不被重视。没有严格的需求调研和分析,最终的软件产品会偏离用户的真正需求。如果没有设计,只能建立一个不稳定的系统结构。如下图所示:

在项目实施过程中,以上各个流程都不应该被忽略(重大项目更是如此),任何一个环节的遗失都可能引起项目方向的偏差,甚至失败。项目管理者可以在此基础上,完善项目管理流程,以降低项目实施的风险。 三、项目文档管理 项目管理者必须在系统开发过程中做好项目文档管理。项目文档是项目实施的依据,也是项目设计、编码、测试、修正、培训和验收的依据。 根据以上项目流程,项目实施过程中应包含以下所必须的文档:

(完整word版)WEB前端开发代码使用要求规范

WEB前端代码规范 规范目的 为提高团队协作效率,便于后台人员添加功能及前端后期优化维护,输出高质量的文档,特制订此文档。本规范文档一经确认,前端开发人员必须按本文档规范进行前台页面开发。本文档如有不对或者不合适的地方请及时提出,经讨论决定后方可更改。 基本准则 符合web标准;语义化html;结构、表现、行为分离;兼容性优良。页面性能方面,代码要求简洁明了有序,尽可能的减小服务器负载,保证最快的解析速度。 文件规范

3.jsp文件命名:英文驼峰式命名,文件名.jsp。按实际模块需求命名。 4.css文件命名:英文驼峰式命名,文件名.css。共用base.css,首页index.css,其他 页面按实际模块需求命名。 5.js文件命名:英文驼峰式命名,文件名.js。共用common.js,其他依实际模块需求命 名。 html书写规范 1.文档类型声明及编码:统一为html5的声明类型;编码统一为 ,书写时利用IDE实现层次分明的缩进。 2.非特殊情况下css文件必须在...之间引入,选择link方式引入而非 @import形式。 3.非特殊情况下js文件必须在页面底部引入。 4.引入样式文件或JavaScript文件时,须略去默认类型声明,写法如下:

11.语义化html,如标题根据重要性用h1-h6(同一页面只能有一个h1),段落标记用p,列表 用ul,内联元素中不可嵌套块状元素。 12.尽可能减少div的嵌套层数。 13.在页面中尽量避免使用内嵌样式表,即在标签内使用style="…"。 14.以背景形式呈现的图片,尽量写入css样式中;重要图片必须加上alt属性; 15.特殊符号使用:尽可能使用代码替代:比如<(<)、>(>)、空格( )、&(&)、 ”(")等等; 16.尽量避免使用过度复杂的HTML结构。 css书写规范 1.编码统一为utf-8。 2.为了避免一些浏览器兼容性问题以及增加样式重用性,每个页面必须引入base.css(详见 附件一),此文件不可随意修改。 3.class与id的使用:id是唯一的并是父级的,class是可以重复的并是子级的,所以id 仅使用在大的模块上,class可用在重复使用率高及子级中。 4.为JavaScript预留钩子的命名,请以js_起始,比如:js_hide,js_show。 5.class与id命名:使用英文命名,命名要语义化,简明化,但不要使用诸如first,last 之类的命名。使用驼峰式和下划线分隔相结合的命名规则,即命名应以父级加子级的命名规范,如:父级的类为simple 子级的类应该为simple_first,以此类推,但是尽量避免出现超过四级的类命名。 6.css属性书写顺序,建议遵循:自身属性-->布局定位属性-->文本属性-->其他属性。此条 可根据自身习惯书写,但尽量保证同类属性写在一起。

项目开发详细设计说明书(超好用模板)完整版

详细设计说明书XX有限公司

修订记录

目录 第一章概述........................................................................... 错误!未定义书签。 1.1.应用模块的目的....................................................... 错误!未定义书签。 1.2.应用模块总体描述................................................... 错误!未定义书签。 1.3.应用模块接口描述................................................... 错误!未定义书签。 1.4.假设条件................................................................... 错误!未定义书签。第二章设计模式(Design pattern) ................................... 错误!未定义书签。第三章类设计....................................................................... 错误!未定义书签。 3.1.分块类图................................................................... 错误!未定义书签。 <类图1> ............................................................ 错误!未定义书签。 <类图n> ............................................................ 错误!未定义书签。 3.2.整体继承关系........................................................... 错误!未定义书签。 3.3.类描述....................................................................... 错误!未定义书签。 <类名1> Class Description............................. 错误!未定义书签。 <类名n> Class Description............................. 错误!未定义书签。第四章交互图....................................................................... 错误!未定义书签。 4.1.<情景编号1: 情景名称> ........................................ 错误!未定义书签。 交互图................................................................ 错误!未定义书签。 例外情况及条件................................................ 错误!未定义书签。 4.2.<情景编号n: 情景名称> ........................................ 错误!未定义书签。第五章状态图....................................................................... 错误!未定义书签。 5.1.<状态图编号1:状态图名称> .................................. 错误!未定义书签。 5.2.<状态图编号n:状态图名称> .................................. 错误!未定义书签。第六章时序流程图............................................................... 错误!未定义书签。第七章用户界面设计说明................................................... 错误!未定义书签。 7.1.用户界面关系........................................................... 错误!未定义书签。 7.2.用户界面具体描述................................................... 错误!未定义书签。 <界面编号1:界面名称〉 ................................. 错误!未定义书签。 <界面编号N:界面名称〉 ................................ 错误!未定义书签。

Web前端开发规范手册参考

Web前端开发规范 参考手册 一、规范目的 1.1 概述 为提高团队协作效率,便于后台人员添加功能,及前端后期优化维护,输出高质量的文档,特制订此文档。本规范文档一经确认,前端开发人员必须按本文档规范进行前台页面开发。本文档如有不对或者不合适的地方请及时提出,经讨论决定后可以更改。 1.2 基本准则 符合web标准,语义化HTML,结构表现行为分离,兼容性优良。页面性能方面,代码要求简洁明了有序,尽可能的减小服务器负载,保证最快的解析速度。 二、规范细则 2.1 文件命名规则 文件名称统一用小写的英文字母、数字和下划线的组合,其中不得包含汉字、空格和特殊字符。命名原则的指导思想: ●一是使得工作组的每一个成员能够方便的理解每一个文件的意义。 ●二是当在文件夹中使用“按名称排例”的命令时,同一种大类的文件能够排列在一 起,以便查找、修改、替换、计算负载量等等操作。 1. HTML命名原则 ●引导文件统一使用index.htm、index.html、ndex.asp文件名(小写)。 ●各子页命名的原则首先应该以栏目名的英语翻译取单一单词为名称。例如: ?关于我们\ aboutus ?信息反馈\ feedback ?产品\ product ●如果栏目名称多而复杂并不好以英文单词命名,则统一使用该栏目名称拼音或拼音 的首字母表示;每一个目录中应该包含一个缺省的html 文件,文件名统一用 index.htm、index.html、index.asp。

2. 图片命名原则 ●图片的名称分为头尾两部分,用下划线隔开,头部分表示此图片的大类性质。例如: 广告、标志、菜单、按钮等。 ●放置在页面顶部的广告、装饰图案等长方形的图片取名:banner。 ●标志性的图片取名:logo。 ●在页面上位置不固定并且带有链接的小图片取名:button 。 ●在页面上某一个位置连续出现,性质相同的链接栏目的图片取名:menu。 ●装饰用的照片取名:pic。 ●不带链接表示标题的图片取名:title。 例如: banner_sohu.gif banner_sina.gif menu_aboutus.gif menu_job.gif title_news.gif logo_police.gif logo_national.gif pic_people.jpg ●鼠标感应效果图片命名规范为"图片名+_+on/off"。 例如: menu1_on.gif menu1_off.gif 3. Javascript命名原则 例如: ●广告条的javascript文件名为ad.js ●弹出窗口的javascript文件名为pop.js 4. 动态语言文件命名原则 以性质_描述,描述可以有多个单词,用“_”隔开,性质一般是该页面得概要。例如:register_form.asp register_post.asp topic_lock.asp 2.2 文件存放位置规范 HTML、CSS、js、images文件均归档至<系统开发规范>约定的目录中。 _Root cn 存放中文HTML文件 en 存放英文HTML文件 flash 存放Flash文件 images 存放图片文件 imagestudio 存放PSD源文件

前端开发设计规范文档样本

前端开发设计规范 目录 前端开发设计规范 (1) 一、HTML使用规范 (1) 1.1、页面文件命名规范 (1) 1.2、页面head部分书写规范 (1) 1.3、HTML元素开发规范 (2) 1.3.1、HTML元素书写规范 (2) 1.3.2、HTML元素命名规范 (4) 二、WEB页面开发规范 (5) 2.1、错误跳转页面的处理 (5) 2.2、提示信息的处理 (5) 2.3、页面的返回 (5) 2.4、提交前数据的判断验证 (5) 2.5、删除操作 (6) 2.6、页面中java代码的使用 (6) 2.7、网站页面布局规范 (7) 2.7.1、前台页面尺寸 (7)

2.7.2、标准网页广告图标规格(参考) (7) 2.7.3、页面字体 (8) 2.7.4、字体颜色 (8) 三、javaScript开发规范 (9) 3.1、javaScript文件命名规范: (9) 3.2、javaScript开发规范 (9) 3.2.1、javaScript书写规范 (9) 3.2.2、javaScript命名规范 (10) 四、css样式规范 (12) 4.1、css样式文件命名规范 (12) 4.1.1、通用样式文件命名规范: (12) 4.1.2、业务类样式文件命名规范 (13) 4.1.3、css样式文件命名须知 (13) 4.2、css样式文件存放目录规范 (13) 4.3、css样式定义规范 (14) 4.3.1、css样式内容顶部注释规范 (14) 4.3.2、css样式内容注释规范 (14) 4.3.3、css样式定义规范 (15) 4.3.4、css样式常用id的命名 (17) 4.3.5、css样式常用class的命名 (18)

Web前端开发规范手册

Web前端开发规范手册 一、规范目的 1.1 概述 (1) 二、文件规范 2.1 文件命名规则 (1) 2.2 文件存放位置 (2) 2.3 css 书写规范 (3) 2.4 html书写规范 (7) 2.5 JavaScript书写规范 (11) 2.6 图片规范 (12) 2.7 注释规范 (13) 2.8 css 浏览器兼容 (13) 一、规范目的 1.1 概述 为提高团队协作效率, 便于后台人员添加功能及前端后期优化维护, 输出高质量的文档, 特制订此文档. 本规范文档一经确认, 前端开发人员必须按本文档规范进行前台页面开发. 本文档如有不对或者不合适的地方请及时提出, 经讨论决定后可以更改此文档. 二、文件规范 2.1 文件命名规则 文件名称统一用小写的英文字母、数字和下划线的组合,其中不得包含汉字、空格和特殊字符;命名原则的指导思想一是使得你自己和工作组的每一个成员能够方便的理解每一个文件的意义,二是当我们在文件夹中使用“按名称排例”的命令时,同一种大类的文件能够排列在一起,以便我们查找、修改、替换、计算负载量等等操作。

a. HTML的命名原则 引文件统一使用index.htm index.html index.asp文件名(小写) 各子页命名的原则首先应该以栏目名的英语翻译取单一单词为名称。例如: 关于我们\ aboutus 信息反馈\ feedback 产品\ product 如果栏目名称多而复杂并不好以英文单词命名,则统一使用该栏目名称拼音或拼音的首字母表示; 每一个目录中应该包含一个缺省的html 文件,文件名统一用index.htm index.html index.asp; b. 图片的命名原则 图片的名称分为头尾两部分,用下划线隔开,头部分表示此图片的大类性质 例如:广告、标志、菜单、按钮等等。 放置在页面顶部的广告、装饰图案等长方形的图片取名:banner 标志性的图片取名为:logo 在页面上位置不固定并且带有链接的小图片我们取名为button 在页面上某一个位置连续出现,性质相同的链接栏目的图片我们取名:menu 装饰用的照片我们取名:pic 不带链接表示标题的图片我们取名:title 范例:banner_sohu.gif banner_sina.gif menu_aboutus.gif menu_job.gif title_news.gif logo_police.gif logo_national.gif pic_people.jpg 鼠标感应效果图片命名规范为"图片名+_+on/off"。 例如:menu1_on.gif menu1_off.gif c. javascript的命名原则 例如:广告条的javascript文件名为ad.js 弹出窗口的javascript文件名为pop.js d. 动态语言文件命名原则 以性质_描述,描述可以有多个单词,用“_”隔开,性质一般是该页面得概要。 范例:register_form.asp register_post.asp topic_lock.asp 2.2 文件存放位置规范 _Root cn 存放中文HTML文件 en 存放英文HTML文件 flash 存放Flash文件 images 存放图片文件 imagestudio 存放PSD源文件 flashstudio 存放flash源文件 inc 存放include文件 library 存放DW库文件 media 存放多媒体文件 project 存放工程项目资料

项目开发流程输出文件清单

技术文件提交清单 1. APQP 标题 计划和项目的先期策划子标题 1.1.1 项目覆盖的产品图纸(2D,3D) 1.1.2 APQP项目策划计划表子标题 1.1. 2.1 项目开发建议和申请书、批准书项目经理提供1.1.2.2 多方论证CFT小组成员及职责 1.1. 2.3 市场调研报告项目经理提供1.1.2.4 技术标准资料清单 1.1. 2.5 顾客的技术要求项目经理提供1.1.2.6 同类产品质量报告 1.1. 2.7 新产品开发设计目标 1.1. 2.8 产品初始材料明细 1.1. 2.9 产品和过程特殊特性 1.1. 2.10 过程流程图 1.1. 2.11 新产品设备/工装/专用量具清单 1.1. 2.12 生产能力分析 1.1. 2.13 所需设备初步清单 1.1. 2.14 项目投资预算 1.1. 2.15 可行性报告 1.1. 2.16 设计和开发评审记录表 1.1. 2.17 管理者支持的批准文件 1.2. 产品试制过程子标题 1.2.1 过程开发计划 1.2.2 产品的模具设计图纸和数据(2D,3D) 1.2.3 模具试制进度计划表 1.2.4 采购目录 1.2.5 产品、材料试验清单 1.2.6 小组可行性承诺 1.2.7 过程流程图 1.2.8 生产场地平面布置图 1.2.9 潜在失效模式及后果分析 1.2.10 控制计划 1.2.11 工序能力分析计划

1.2.12 MSA分析计划 1.2.13 主要设备清单 1.2.14 人员培训申请单 1.2.15 培训记录行政部提供 1.2.14 产品包装标准规范营业部提出要求1.2.15 管理者支持 1.2.16 潜在失效模式及后果分析 1.2.17 控制计划 1.2.18 作业指导书 1.2.19 检验指导书 1.3 试生产过程子标题 1.3.1 试生产计划 1.3.2 生产日期及生产数量的确定 1.3.3 产品/过程质量评审 1.3.4 试生产总结-批准正式批量投产 1.3.5 产品质量策划总结和认定 1.3.6 管理者支持的批准文件 2 MSA测量系统的统计与分析子标题 2.1MSA分析计划品质部提供 2.2测量系统分析报告品质部提供 3潜在失效模式及后果分析(PFMEA) 4PPAP 子标题 4.1 过程流程图 4.2 作业指导书 4.3 产品检验标准(检验指导书) 4.4 潜在失效模式及后果分析(PFMEA) 4.5 控制计划 4.6 零件提交保证书 4.6 客户认可接收的文件客户提供 5SPC过程控制统计子标题 5.1PPK过程能力指数分析品质部提供5.2CPK制成能力控制指数分析品质部提供

软件开发文档模板

软件开发文档模板 1 可行性研究报告 可行性研究报告的编写目的是:说明该软件开发项目的实现在技术、经济和社会条件方面的可行性;评述为了合理地达到开发目标而可能先择的各种方案;说明论证所选定的方案。可行性研究报告的编写内容要求如下: 1.1 引言 1.1.1 编写目的 1.1.2 背景 1.1.3 定义 1.1.4 参考资料 1.2 可行性研究的前提 1.2.1 要求 1.2.2 目标 1.2.3 条件、假定和限制 1.2.4 进行可行性研究的方法 1.2.5 评价尺度 1.3 对现有系统的分析 1.3.1 数据流程和处理流程 1.3.2 工作负荷 1.3.3 费用开支 1.3.4 人员 1.3.5 设备 1.3.6 局限性 1.4 所建议的系统 1.4.1 对所建议系统的说明 1.4.2 数据流程各处理流程 1.4.3 改进之处 1.4.4 影响 1.4.4.1 对象设备的影响 1.4.4.2 对软件的影响 1.4.4.3 对用户单位机构的影响 1.4.4.4 对系统动行的影响 1.4.4.5 对开发的影响 1.4.4.6 对地点和设施的影响 1.4.4.7 对经费开支的影响 1.4.5 局限性 1.4.6 技术条件方面的可行性 1.5 可选择其他系统方案 1.5.1 可选择的系统方案 1 1.5.2 可选择的系统方案 2 …… 1.6 投资及收益分析 1.6.1 支出 1.6.1.1 基本建设投资

1.6.1.2 其他一次性支出 1.6.1.3 非一次性支出 1.6.2 收益 1.6. 2.1 一次性收益 1.6. 2.2 非一次性收益 1.6. 2.3 不可定量的收益 1.6.3 收益/投资比 1.6.4 投资回收周期 1.6.5 敏感性分析 1.7 社会条件方面的可行性 1.7.1 法律方面的可行性 1.7.2 使用方面的可行性 1.8 结论 2 项目开发计划 编制项目开发计划的目的是用文件的形式,把对于在开发过程中各项工作的负责人员、开发进度所需经费预算、所需软、硬件条件等问题作出安排记载下来,以便根据本计划开展和检查本项目的开发工作。编制内容要求如下: 2.1 引言 2.1.1 编写目的 2.1.2 背景 2.1.3 定义 2.1.4 参考资料 2.2 项目概述 2.2.1 工作内容 2.2.2 主要参加人员 2.2.3 产品及成果 2.2. 3.1 程序 2.2. 3.2 文件 2.2. 3.3 服务 2.2. 3.4 非移交产品 2.2.4 验收标准 2.2.5 完成项目的最迟期限 2.2.6 本计划的审查者与批准者 2.3 实施总计划 2.3.1 工作任务的分解 2.3.2 接口人员 2.3.3 进度 2.3.4 预算 2.3.5 关键问题 2.4 支持条件 2.4.1 计算机系统支持 2.4.2 需要用户承担的工作 2.4.3 需由外单位提供的条件 2.5 专题计划要点

设计手册

第一章设计要求 设计家庭清洁机器人的工作内容和要求:运行机构形式:轮式最高行进速度: 0.5m/ s 转弯半径:0 高度:<100mm 宽度:<400mm 清洁方式:吸尘、扫刷 一次充电连续工作时间: 0.5小时 营示方式: LED闪光 具有自动路径规划避障功能 具确自动充电装置 第二章家庭清洁机器人的关键技术 家庭清洁机器人的关键技术吸尘机器人系统通通常由四个部分组成:移动机构、感知系统、控制系统和吸尘系统。移动机构是吸尘机器人的主题,决定了吸尘器的运动空间,一般采用轮式机构。感知系统一般采用超声波测距仪、接触和接近觉传感器、红外线传感器和 CCD摄像机等。 目前发展较快、对吸尘机器人发展影响较大的关键技术是:传感技术,智能控制技术、路径规划技术、吸尘技术、电源技术等 2. 1传感技术 为了让吸尘机器人正常工作,必须对机器人位置、姿态、速度和

系统内部状态进行监控,还要感知机器人所出工作环境的静态和动感信息,使得吸尘机器人相应的工作顺序和操作内容能自然地适应工作环境的变化。 通常采用的传感器分为内部传感器和外部传感器。其中内部传感器有:编码器、线加速度计、陀螺仪、磁罗盘等。其中编码器用于确定当前机器人的位置,线加速度计获取线加速度信息,进而得到线加速度和位置信息;陀螺仪测量移动机器人的角度、角速度、角加速度以得到机器人的姿态角、运动方向和转动时运动方向的改变等绝对航向信息。外部传感器有视觉传感器、超声波传感器、红外传感器、接触很接近传感器。视觉传感器采用 CCD摄像机进行机器人的视觉导航与定位、目标识别和地图构造等;超声波传感器测量机器人工作环境中障碍物的距离信息和地图构造等。红外线传感器大多采用红外接近开关来探测机器人工作环境中的障碍物以及避免碰撞。接触和接近觉传感器多用于避碰规划。 2. 2路径规划技术 根据机器人对环境信息知道的程度不同,可分为为两种类型:环境信息完全知道的全局路径规划和环境信息完全未知或部分未知,通过传感器在线地对机器人的工作环境进行探测,以获取障碍物的位置、形状和尺寸等信息的局部路径规划。全局路径规划包括环境建模和路径搜索策略两个子问题。其中环境建模的主要方法有:可视图法(V‐Graph)、自由空间法(Free spaccApproach)和栅格法(Grids)等

软件项目开发工作流程

软件项目开发工作流程 一、简述 对于一个新项目,从可行性研究到产品交货整个生存阶段将经历如下十大流程: 1、项目可行性研究阶段 2、立项阶段 3、需求分析阶段 4、开发策划阶段 5、设计阶段 6、编码实现阶段 7、测试阶段 8、验收阶段 9、产品交付使用 10、维护阶段 二、项目组基本组成及岗位职责 新项目立项时会成立项目组,不同的项目组成员有不同的职责,一个项目组成员也可以身兼多职,但不可身兼全职。 a项目负责人:负责项目的管理、组织、对技术、进度、质量全面负责。 b质量保证人员:负责质量保证工作计划的落实和软件的质量保证。 C配臵管理人员:负责本项目的配臵管理工作,对本项目的文档、程序是否符合规程文件的要求进行形式化的检查。 D分析人员:主要负责本项目的需求分析工作。 E设计人员:主要负责本项目的设计工作。 F程序员:按设计要求和有关标准进行编程工作。 G测试人员:负责单元测试、组合测试和总装测试工作。 H文档人员:负责本项目有关文档的编写工作。 I产品经理:协助进行产品研制计划制定、产品发布与产品推广等,在产品开发中,充分代表用户的利益,提供建议,负责在产品功能与出品日期二者之间的权衡;负责产品市场营销、产品销售和市场推广过程。(通常由营销部门或中试部门人员担任) 三、软件开发流程 3.1 可行性研究阶段 如果是公司自主开发项目,可行性研究通常是由公司技术负责人根据公司产品规划和市场需求,在要开展新项目前通过部门负责人指定人员进行的前期调研工作,可行性研究负责人员对产品的市场需求、技术发展、市场定位、功能需

求、经济效益、进度需求、风险分析等进行可行性研究,提供产品立项建议,拟制可行性研究报告,由部门负责人指定营销部门配合可行性分析人员,技术负责人协助安排。可行性分析完毕后由总工办组织对可行性研究报告进行评审,评审通过后,总工办组织进行立项工作。 如果是系统集成部外接的系统集成项目,在系统集成部与客户签订合同之前,均应对将签项目进行资源、技术、市场的可行性分析,可行性分析通过后、签订合同前由总工办组织相关人员对合同条款进行评审,评审通过后,总工办组织进行立项工作。 本阶段提交的文档:项目可行性研究任务书(技术负责人或部门负责人下达) 项目可行性研究报告(可行性研究人员编写) 系统集成项目合同 质量记录:可行性分析评审报告 3.2立项阶段 可行性分析评审通过后,由开发部门经理下达立项任务,指定相关人员填写立项申请报告报批。报批通过后,由部门经理与技术负责人协商,下达开发任务书,经技术负责人审核确认后,报公司批准。批准立项后项目进度应以立项申请报告中的阶段进度为准,如果进度要调整,需填写进度调整申请报告报批。 本阶段提交的文档:项目立项申请报告 开发任务书 3.3 需求分析阶段 承办单位根据交办单位提出的技术要求和相应的软件任务书以及其它有关文件,与交办单位协作,确定详细的软件需求,该阶段完成的软件需求规格说明经审定和批准后将作为整个软件开发工作的基础列入配臵管理的基线,在本阶段可利用快速原型法使比较含糊的具有不确定性的软件需求(主要是功能)明确化。能给本公司开发的软件的“需求基线”确定提供一个讨论、进一步完善的基础。在本阶段,由产品经理负责,其他人员配合,编写产品规格说明书,此说明书面向最终用户和领导,主要描绘产品的形状以及功能、性能、功能特性、性能特性。由项目经理负责编写系统技术方案书,描述公司初次使用的技术的详细解决方案。本阶段完毕后对需求分析进行评审,出具需求分析评审报告。 本阶段提交的文档:软件需求规格说明书。 原型分析说明书 产品规格说明书 系统技术方案书 质量记录:需求分析评审报告 提交的软件:产品的原型(注:如果时间有限,可以只编写原型分析说明书而不作原型) 3.4开发策化阶段

ios开发规范文档

命名 命名规则对于维护代码来说是非常重要的,。Objective-C方法名往往很长,不过这也有好处,让很多注释变得毫无意义。 本文推荐驼峰法,也是Objective-C社区的标准。 驼峰法分小驼峰法和大驼峰法。小驼峰法:除第一个单词之外,其他单词首字母大写。大驼峰法相比小驼峰法,大驼峰法把第一个单词的首字母也大写了。 1.基本原则 1.1 清晰 又清晰又简洁是最好的了,但简洁不如清晰重要。总的讲不要使用单词的简写,除了非常常用的简写以外,尽量使用单词全称。API的名称不要有歧义,一看你的API就知道是以什么方式做了什么事情,不要让人有疑问 1.2 一致性 做某个事情代码通常都叫这个名字,比如tag、setStringValue,那么你也这么叫。你在不确定怎么起名字的时候,可以参考一些常用的名字:Method Arguments 2. 类命名 类名(不包括类别和协议名)应该用大写开头的大驼峰命名法。类名中应该包含一个或多个名词来说明这个类(或者类的对象)是做什么的。 在应用级别的代码里,尽量不要使用带前缀的类名。每个类都有相同的前缀不能提高可读性。不过如果是编写多个应用间的共享代码,前缀就是可接受并推荐的做法了(型如MBAPhotoBrowser )。 示例1: @interface ImageBrowseView :UIView @end 示例2:(带前缀MBA) @interface MBAPhotoBrowser :UIView @end

3. 类别命名 类名+标识+扩展(UIImageView +HP+Web) 例:如果我们想要创建一个基于UIImageView的类别用于网络请求图片,我们应该把类别 放到名字是UIImageView+HPWeb.h的文件里。UIImageView为要扩展的类名,HP为专属标识,Web为扩展的功能。 类别的方法应该都使用一个前缀(型如hp_myCategoryMethodOnAString ),以防止Objective- C代码在单名空间里冲突。如果代码本来就不考虑共享或在不同的地址空间(address- space),方法命名规则就没必要恪守了。 类别HPWeb头文件,UIImageView+HPWeb.h如下: @interface UIImageView (HPWeb) - (void)hp_setImageWithURLString:(NSString *)urlStr; @end 4. 方法命名 方法使用小驼峰法命名, 一个规范的方法读起来应该像一句完整的话,读过之后便知函数 的作用。执行性的方法应该以动词开头,小写字母开头,返回性的方法应该以返回的内容 开头,但之前不要加get。 示例: - (void)replaceObjectAtIndex:(NSUInteger)index withObject:(id)anObject; (instancetype)arrayWithArray:(NSArray *)array;

项目开发详细设计说明书(超好用实用模板),完整版

实用文案 详细设计说明书 XX有限公司

修订记录

目录 第一章概述 (5) 1.1.应用模块的目的 (5) 1.2.应用模块总体描述 (5) 1.3.应用模块接口描述 (5) 1.4.假设条件 (5) 第二章设计模式(Design pattern) (6) 第三章类设计 (7) 3.1.分块类图 (8) 3.1.1.<类图1> 8 3.1.2.<类图n> 8 3.2.整体继承关系 (8) 3.3.类描述 (9) 3.3.1.<类名1> Class Description 9 3.3.2.<类名n> Class Description 10 第四章交互图 (12) 4.1.<情景编号1: 情景名称> (12) 4.1.1.交互图 12 4.1.2.例外情况及条件 13 4.2.<情景编号n: 情景名称> (13) 第五章状态图 (14) 5.1.<状态图编号1:状态图名称> (14)

5.2.<状态图编号n:状态图名称> (15) 第六章时序流程图 (16) 第七章用户界面设计说明 (18) 7.1.用户界面关系 (18) 7.2.用户界面具体描述 (18) 7.2.1.<界面编号1:界面名称〉 18 7.2.2.<界面编号N:界面名称〉 19 第八章测试考虑 (20) 第九章附录 (21) 9.1.附录A 代码举例 (21) 9.2.附录B 设计问题 (21) 9.2.1.<设计问题1> 21 9.2.2.<设计问题n> 21

第一章概述 1.1.应用模块的目的 请明确客户建立应用模块的目的。 1.2.应用模块总体描述 描述应用模块的总体功能。 1.3.应用模块接口描述 简要描述本应用模块的公共接口,具体接口会在相应的类中进行具体描述。建议采用列表的方式。 1.4.假设条件 列出在问题领域,项目方案及其它影响系统设计的可能方面内,应当成立的假设条件。包括系统的约束条件和应遵循的标准。

Web前端开发规范手册

Web前端开发规范手册 修订历史记录 日期版本说明作者 2012年12月31日 1.0初稿施昀 2012年01月05日 1.1施昀、戴静2012年01月07日 1.2施昀 目录 修订历史记录 (1) 一、规范目的 (2) 1.1概述 (2) 二、基本准则 (2) 三、文件规范 (3) 2.1文件命名规则 (3) 2.1.1HTML的命名原则 (3) 2.1.2图片的命名原则 (3) 2.1.3.javascript的命名原则 (4) 2.1.4动态语言文件命名原则 (4) 2.2文件存放位置规范 (4) 2.3CSS书写规范 (4) 2.3.1基本原则 (4)

2.3.2注意细则 (5) 2.3.3命名规则 (6) 2.4html书写规范 (9) 2.4.1head区代码规范 (9) 2.4.2body区代码规范 (10) 2.5JavaScript书写规范 (10) 2.6图片规范 (10) 2.7注释规范 (11) 2.7.1html注释 (11) 2.7.2css注释 (11) 2.7.3JavaScript注释 (11) 四、执行模式 (12) 一、规范目的 1.1概述 提高团队协作效率 便于前端开发以及后期优化维护 方便新进的成员快速上手 输出高质量的代码 本规范文档一经确认,前端开发人员必须按本文档规范进行前台页面开发。本文档如有不对或者不合适的地方请及时提出,经讨论决定后可以更新此文档。 二、基本准则 符合web标准,语义化html,结构表现行为分离,兼容性优良。 代码要求简洁明了有序,尽可能的减小服务器负载,保证最快的解析速度。

开发时需要遵循如上基本准则,特殊情况可以有所宽限,如一些老项目的页面改造。 三、文件规范 2.1文件命名规则 [使用场景:在新建网页、图片、脚本、CSS文件时,根据此规则给文件命名并放入指定位置] 文件名称统一用小写的英文字母、数字和下划线的组合,其中不得包含汉字空格和特殊字符。命名原则的指导思想一是使得你自己和工作组的每一个成员能够方便的理解每一个文件的意义,二是当我们在文件夹中使用“按名称排例”的命令时,同一种大类的文件能够排列在一起,以便我们查找、修改、替换、计算负载量等等操作。 2.1.1HTML的命名原则 索引文件统一使用index.htm index.html index.asp文件名。 如果栏目名称多而复杂并不好以英文单词命名,则统一使用该栏目名称拼音或拼音的首字母表示。 每一个目录中应该包含一个缺省的html文件,文件名统一用index.htm index.html index.asp。 2.1.2图片的命名原则 图片的名称分为头尾两部分,用下划线隔开,头部分表示此图片的大类性质。 例如:广告、标志、菜单、按钮等等。 放置在页面顶部的广告、装饰图案等长方形的图片取名:banner 标志性的图片取名为:logo 在页面上位置不固定并且带有链接的小图片我们取名为button 在页面上某一个位置连续出现,性质相同的链接栏目的图片我们取名:menu 装饰用的照片我们取名:pic 不带链接表示标题的图片我们取名:title 范例:banner_sohu.gif banner_sina.gif menu_aboutus.gif menu_job.gif title_news.gif logo_police.gif logo_national.gif pic_people.jpg

项目开发流程文档

项目开发流程文档 目录:1,明确需求阶段 2,产品原型阶段 3,UI设计阶段 4,前端设计页面阶段 5,后台开发阶段 6,代码测试阶段 7,上线阶段 8,代码维护阶段 一:明确需求阶段 这个方面基本是产品经理来确定一个模块的需求,然后跟后台开发人员开会讨论需求的合理性以及存在的必要性,后台开发人员可以提出自己的意见,但是确定权归项目经理。 二:产品原型阶段 确定了需求之后,产品经理开始着手设计产品原型。原型设计好之后,交由需求方确定原型的合理性(这个步骤一般可以省略)。然后交由开发人员,讨论功能的合理性以及存在的必要性。这些过程完毕之后,产品原型正式生效。再由产品经理写一套开发文档。 三:UI设计阶段 这个阶段基本上就是一个模块的正式开始阶段,UI工程师根据产品经理给出的原型,设计出一套符合要求,且审美兼具的UI出来。 四.前端设计页面阶段 当UI设计师没每设计出一套UI出来,前端工程师就可以着手根据UI设计的原图。设计自己的思路,将UI原图用代码写出来,包括各种特效效果,色值,以及整个页面布局的合力性。 五. (中间插一个步骤:当三,四这两个步骤正在执行的时候,这是后台开发人员要做的 就是合理的设计数据库。数据库的设计需要一个经验比较丰富的开发人员来完成,因为数据库是一个项目的核心所在,也是一个公司业务的核心所在。它的重要性当然不言而喻,所以一个合理的数据库可以带来以后开发的便利,以及整个业务的融合性。) 六.后台开发阶段 很多人说:页面没有出来之前,后台可以先把代码写出来,等页面出来了,在进行嵌套。对于这种说法,我本人是持反对态度的。因为没有页面的出现,我们是很难进行数据的展示的,没有数据的展示,我们也很难发现我们代码中的bug。修改bug除了开启调式模式之外,另外一个就是通过服务器与客户端之间的一次次的请求中来发现问题的。所以我的意见就是

WEB前端开发规范文档+CSS命名规范

WEB前端开发规范文档+CSS命名规范 规范目的 为提高团队协作效率, 便于后台人员添加功能及前端后期优化维护, 输出高质量的文档, 特制订此文档. 本规范文档一经确认, 前端开发人员必须按本文档规范进行前台页面开发. 本文档如有不对或者不合适的地方请及时提出, 经讨论决定后方可更改. 基本准则 符合web标准, 语义化html, 结构表现行为分离, 兼容性优良. 页面性能方面, 代码要求简洁明了有序, 尽可能的减小服务器负载, 保证最快的解析速度. 文件规范 1. html, css, js, images文件均归档至<系统开发规范>约定的目录中; 2. html文件命名: 英文命名, 后缀.htm. 同时将对应界面稿放于同目录中, 若界面稿命名为中文, 请重命名与html文件同名, 以方便后端添加功能时查找对应页面; 3. css文件命名: 英文命名, 后缀.css. 共用base.css, 首页index.css, 其他页面依实际模块需求命名.; 4. Js文件命名: 英文命名, 后缀.js. 共用common.js, 其他依实际模块需求命名. html书写规范 1. 文档类型声明及编码: 统一为html5声明类型; 编码统一为, 书写时利用IDE实现层次分明的缩进; 2. 非特殊情况下样式文件必须外链至...之间;非特殊情况下JavaScript文件必须外链至页面底部; 3. 引入样式文件或JavaScript文件时, 须略去默认类型声明, 写法如下: Example Source Code [https://www.wendangku.net/doc/f413559878.html,]

AntDesignPro开发手册精编版

AntDesignPro开发手册 修订历史记录

目录

1.前言

1.1目的 让不熟悉Ant Design Pro 的开发人员快速掌握开发方式 1.2概述 Ant Design Pro是一个前端设计解决方案,由蚂蚁金服体验技术部出品/维护。 核心技术组成: ?ES2015+ JavaScript语言的新标准 ?React 用于构建用户界面的JAVASCRIPT 库 ?dva 是基于(redux(状态管理)+ react-router(路由库)+ redux-saga(异 步中间件)等)的一层轻量封装 ?g2 一套基于可视化编码的图形语法 ?antd React组件 2.开发环境 2.1 Node.js 安装配置 Node.js安装包及源码下载地址为:https://https://www.wendangku.net/doc/f413559878.html,/en/download/ 2.2安装方式 2.2.1直接clone git 仓库

git clone --depth=1 https://https://www.wendangku.net/doc/f413559878.html,/ant-design/ant-design-pro.git my-project cd my-project 2.2.2使用集成化的命令行工具ant-design-pro-cli。 npm install ant-design-pro-cli -g #安装脚手架 mkdir my-project cd my-project pro new # 创建一个新项目 2.3 目录结构 ├──mock # 本地模拟数据 ├──public # 公共资源 │└──favicon.ico # 网站图标 ├──src │├──assets # 本地静态资源 │├──common # 应用公用配置,如导航信息 │├──components # 业务通用组件 │├──e2e # 集成测试用例 │├──layouts # 通用布局 │├──models # 数据交互 │├──routes # 业务页面入口和常用模板 │├──services # 后台接口服务 │├──utils # 工具库 │├──g2.js # 可视化图形配置 │├──theme.js # 主题配置 │├──index.ejs # HTML 入口模板 │├──index.js # 应用入口 │├──index.less # 全局样式 │└──router.js # 路由入口 ├──tests # 测试工具 ├──README.md # 项目说明 └──package.json # 项目配置文件 2.4 项目初始化

相关文档