美国某大型软件的开发计划日程安排 (转)

美国某大型软件的开发计划日程安排 (转)[@more@] 

ideograph">这是以前从网络上找到的某软件(不知道使用真实名称是否有争议,暂且称之为XXX ‘97吧)的开发计划日程安排,我想它是有可学之处的,就翻译了过来,希望能有所借鉴,其中某些该软件技术方面的细节,并不影响对开发计划的理解,所以没有翻译,鉴于本人英文水平有限,可能有错误之处。虽然不同的情况开发计划不同,但该文档对于规范开发是有启示的。文中字样“注:”为译者添加。我无法给出来源,只好贴在原创里面了

译者注

 XML:namespace prefix = o ns = "urn:schemas-microsoft-com:Office:office" />

以下为实际内容

XXX ‘97 开发计划

戴维更新于1997年2月

介绍

这个文档为XXX’97开发的日程安排 ,它用于为《开发议案》中的三部分内容服务:XXX’97开发文档和它的用于YY2.0的OLE控件 ,某用于DTP的服务包,和某独立的浏览器

XXX’97和XXX’97J(远东版)将被作为可回调的绘图部件服务,作为Office’96和Publisher’96之间的信息交换载体。

这个日程使用Office系列的excel组件建立,这些宏可以生成可读性及强的报表,包括每周的日程进展情况,如果日程可以在网络上使用,就不必进行打印工作。

XXX’97.XLS – 包括建立所有的相关文档部件。

XXX’97J.XLS -包括建立远东版所有的相关文档部件。将在XXX’97非远东部分完成后指定三个开发者完成。

在开发阶段,日程将在每周更新。每个月,程序员们必须重新在他们的相关日程上签名并汇总到戴维处,由戴维统一控制日程计划安排。

关于本工程的细节问题,请联系负责人Ho,他将指导你找到相关可用文档,如:本工程开发规范。

目标日期和阶段

本日程的各阶段时间的制定主要基于日程安排,虽然它也在很大程度上受其它客户端的影响:如浏览器、YY2.0等。

开发由两个主要阶段组成,第一阶段:信息可以被投递到它的回调服务集成环境; 第二阶段:其余代码的完成。工程文档的设计也将遵照这些阶段进行。

在完成XXX’97后,三个开发者将被立即分配到XXX’97J远东工程部分。

下面的表格中为预计的重要目标的日期。

表格1:目标日程安排

5/1/96

最终的议案及日程安排结束,第一阶段开始 (14 个星期)

7/31/96

第一阶段代码完成。完善期开始 (4个星期)

8/15/96

第一个可用的程序提交

8/28/96

第二阶段开始 (14个星期)

11/27/96

第二阶段结束,代码完成。

1/20/97

开始XXX’97J版开发,三个开发者将主要完成远东版发布和在MIPS平台的编译的工作(12个星期)

2/15/97

正式版XXX’97发布,它包括(… …)

4/15/97

XXX’97J版代码完成

6/15/97

正式版XXX’97J发布

各阶段日程细节

每个阶段包括开发部分14个星期,紧接着4周的稳定、完善期。最后阶段还有4周附加的完善期。

每个开发部分以47天作为一个段,其中有14天的内部完善工作日,6天的病、节假日,和2.5天的代码检察。

下表显示每个阶段有多少天被分配。(注:该算法是按照每周5天计算的)

表 2:  阶段定义

主要阶段的开发期 - 70 天

日程安排项  47 天 (67%)

 

内部完善期    14 天 (20%)

(这个巩固阶段被算在主要阶段中是为了鼓励开发者立刻修复新出现的错误,以便程序部件一直保持稳固。)

 

病假、节假日等  6 天(8.5%)

正常情况下一个阶段每个开发者可以有1天病假

在工程中,(注:所处的日期关系,考虑到阶段中的法定节假日),第一阶段有2个假日,第二阶段有3个假日,J版本开发阶段有1个假日。

开发者平均每个阶段可赶上3或4个假日。

 

内部完善-代码回顾检察阶段 2.5 天(3.5%)

每个阶段有2.5天的代码检察,这个数字对于几个程序员来说就显得多一点。

 

 

主要阶段的缓冲、巩固完善期- 20 天。

阶段完善、错误修正时间一共占据了以90天为一大阶段时间的22%。所有完善、巩固、缓冲的时间(包括每个阶段的14天)占据工程时间的38%,相对于47天的开发任务日程,有34天的缓冲和巩固时间。

当XXX’97的测试结束后,这个完善阶段才真正的结束。(注:这意味着虽然你有这么多完善时间,或者说花这么多时间完善,但是如果没有通过测试,那么还不算完)

主要工作项

介绍…

图1:

…. ….

图2:

…. ….

开发资源

开发组主要成员:戴维(主要负责人和代码划分)AA(客户端接口) … … XXX(xxx)

将于某月某日左右从别的任务脱身加入本开发组的成员 M1(… …),M2(… …)

J版的开发将由J1(… …) J2(… …)J3(… …)完成

表<

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10790690/viewspace-951608/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/10790690/viewspace-951608/

XXX航空移动化应用平台项目 1 投标书 13 2 规格偏离表 13 3 资格证明文件 13 3.1法人营业执照(三证合一) 13 3.2法定代表人授权书 13 3.3 投标人的资信证明 13 3.4 招标文件要求的其他资格证明文件 15 3.4.1投标单位资质证书及项目人员资格证书 15 3.4.1.1 CMMI等级登记证书 15 3.4.1.2 ISO9001质量管理体系认证证书 15 3.4.1.3 软件企业认证证书 15 3.4.1.4 计算机软件著作权登记书-SDK 15 3.4.1.5计算机软件著作权登记书-MAS 15 .4.1.6计算机软件著作权登记书-MMS 16 3.4.1.7计算机软件著作权登记书-EMM 16 3.4.1.8计算机软件著作权登记书-MDM 16 3.4.1.9 项目人员证书 16 3.4.2投标单位近3年内获国家及地方政府荣誉证书 18 3.4.2.1 2015年度中国移动互联网行业领军企业奖 18 3.4.2.2 2014-2015年度云计算应用优秀实践单位奖 18 3.4.2.3 2014年度中国最具影响力品牌奖 19 3.4.2.4 2013年度最佳技术服务提供商 19 3.4.2.5 2013年度中国移动应用平台最具影响力奖 19 3.4.2.6 2014移动生产力十大优秀案例奖 19 3.4.3投标单位综合情况审查表 19 3.4.4拟派项目经理资格审查表 20 3.4.5承担本项目主要技术人员和售后服务人员表 20 3.4.6最近两年主要开发实施同类型企业相同或类似系统的开发案例 21 3.4.6.1案例合同首尾页 21 3.4.6.2 系统开发主界面截图 22 4 项目解决方案 26 4.1 项目解决方案内容 26 4.1.1 系统总体目标、设计架构、系统详细设计方案 27 4.1.1.1 设计原则 27 1. 统一设计原则 27 2. 稳定性原则 27 3. 统一设计原则 27 4. 稳定性原则 27 5. 先进性原则 27 6. 高可靠/高安全性原则 27 7. 开放性原则 28 8. 适用性原则 28 9. 可扩展性原则 28 10. 操作/维护的易用性原则 28 11. 高可靠/高安全性原则 28 4.1.1.2 架构设计 29 4.1.1.2.1. 系统架构设计 29 4.1.1.2.2. 业务系统架构设计 31 4.1.1.2.3. 业务处理架构 32 4.1.1.2.4. 网络拓扑图 33 4.1.1.3 技术路线 35 4.1.1.3.1 统一的移动构建平台 35 4.1.1.3.2 Hybrid移动开发引擎 35 4.1.1.3.3 面向服务的SOA接口集成 35 4.1.1.3.4 高并发处理机制 36 4.1.1.3.5 高效的内存数据库 36 4.1.1.3.6 兼容多种集成模式 36 4.1.1.3.7 开放式的框架设计 36 4.1.1.3.8 数据库选型 36 4.1.1.4 应用工具 37 4.1.1.4.1. 开发工具 37 4.1.1.4.2. 分析设计工具 38 4.1.1.4.3. 项目管理辅助工具 38 4.1.1.4.4. 测试工具 39 4.1.1.4.5. 统计工具 40 4.1.1.4.6. 开发语言 42 4.1.1.4.7. 辅助软件工具及其效果 44 4.1.1.5 移动平台建设方案 45 4.1.1.5.1. 移动业务整合平台(APPCAN MAS) 45 4.1.1.5.2. 移动业务开发平台(APPCAN SDK) 53 1. 音频对象API 55 2. 电话对象API 55 3. 照相机对象API 55 4. 剪贴板对象API 55 5. 日期控件API 55 6. 联系人对象API 55 7. 数据库对象API 55 8. 设备信息对象API 55 9. 下载对象API 55 10. 邮件对象API 55 11. 文件管理对象API 55 12. 图片浏览对象API 56 13. Jabber对象API 56 14. 位置服务对象API 56 15. 日志log输出对象API 56 16. 彩信对象API 56 17. 支付宝API 56 18. 二维码扫描对象API 56 19. 传感器对象API 56 20. 短信对象API 57 21. Socket对象API 57 22. 上传对象API 57 23. 视频对象API 57 24. widget对象API 57 25. 平台对象API 57 26. 多窗口机制API 57 27. 跨域访问对象API 57 28. zip压缩解压缩API 57 29. 百度广告推广接口 57 30. 百度地图接口 57 31. 百度统计接口 58 32. 数据统计分析自定义事件接口 58 33. 微博分享接口 58 34. 自定义编辑框接口 58 35. 游戏引擎接口 58 (1) 插件扩展 58 AppCan IDE 启动画面 62 AppCan IDE 代码编辑界面 63 AppCan IDE模拟器与调试器 63 AppCan IDE 本地打包界面 64 AppCan UI框架控件 65 AppCan Player示意图 66 AppCan模拟器 67 Mac Mini服务器 68 AppCan SDK套装管理后台-项目列表 69 AppCan SDK套装管理后台-项目管理 69 AppCan SDK套装管理后台-引擎升级 70 4.1.1.5.3. 移动业务管理平台(APPCAN EMM) 71 4.1.1.6 前端应用建设方案 78 4.1.1.6.1. 机票预订 78 4.1.1.6.2. 订单管理 82 4.1.1.6.3. 航班动态 86 4.1.1.6.4. XXX商店 90 4.1.1.6.5. 会员注册\登录 93 4.1.1.6.6. 常用乘机人管理 95 4.1.1.6.7. 机票验真 97 4.1.1.6.8. 促销专区 98 4.1.1.6.9. 更多服务 99 4.1.1.6.10. 主页 103 1、 功能性:主页面集成APP中所有功能模块,用户可应用功能模块快速使用需求功能。 103 2、 经济性与宣传性:通过轮播图、广告、促销信息、资讯等展示形式满足XXX航空的宣传需求与广告需求,达到增加收益的目的。 103 3、 美观性:页面设计根据XXX航空整体UI设计思想为依据进行设计,使用户一目了然具备XXX航空的代表性和与其他航空公司的差异化,在此基础上进行深入设计,如根据季节设计清爽的界面、根据时下热播电影设计主题界面等。 103 4.1.1.7 后台管理系统建设方案 104 4.1.1.6.1. 移动平台业务管理系统 105 (1) 应用趋势统计 110 4.1.1.6.2. 移动平台会员管理中心 123 4.1.1.8 非功能性方案 126 4.1.1.7.1. 跨平台解决方案 126 AppCan应用引擎构成图 126 4.1.1.7.2. 消息推送解决方案 127 4.1.1.7.3. 消息/数据可靠性和即时性解决方案 129 4.1.1.7.4. 大数据推送解决方案 129 4.1.1.7.5. 用户操作行为分析解决方案 130 HTML5中国统计分析案例图 132 4.1.1.7.6. 业务系统整合解决方案 132 4.1.1.7.7. 大并发时保证后台业务系统可用性解决方案 136 4.1.1.7.8. 性能解决方案 137 4.1.1.7.9. 接口解决方案 139 4.1.1.7.10. 易用性解决方案 139 4.1.2 软件及硬件配置方案 141 1. 硬件配置 141 2. 软件配置 142 (1) 软件安装配置 142 (2) 软件版本要求 142 4.1.3 项目开发组组成及各成员职责分配方案 144 4.1.3.1. 项目工作方法 144 4.1.3.2. 项目组织结构 145 1. 项目实施领导小组 145 2. 项目经理 146 3. SQA组 146 4. 产品设计组 146 5. UI设计组 146 6. 手机端开发组 147 7. 后台系统开发组 147 8. 测试验收组 147 9. 角色和责任 147 4.1.3.3. 关键人员简历 150 4.1.4 项目管理方案 150 4.1.4.1. 项目例会 150 4.1.4.1.1. 项目协调会 150 4.1.4.1.2. 项目启动会 150 4.1.4.1.3. 现场安装前的工程协调会 150 4.1.4.1.4. 试运行前的工程协调会 151 4.1.4.2. 工作文档评审 151 4.1.4.2.1. 设计评审时机 151 4.1.4.2.2. 设计评审的形式 152 4.1.4.2.3. 设计评审的准备 153 4.1.4.2.4. 设计评审的实施 153 4.1.4.2.5. 对发现问题的处理和跟踪措施 153 4.1.4.2.6. 质量记录的控制 154 4.1.4.3. 项目风险控制 154 4.1.4.3.1. 管理风险 154 4.1.4.3.2. 技术风险 155 4.1.4.3.3. 人员风险 155 4.1.4.4. 项目质量管理 156 5.1.4.4.1. 质量管理过程 156 5.1.4.4.2. 质量管理组织 156 SQA组需参与的关键评审工作任务表 157 4.1.4.5. 变更管理 158 4.1.4.5.1. 需求分级管理 158 4.1.4.5.2. 全生命周期变更管理 159 4.1.4.5.3. 需求变更管理原则 160 4.1.4.5.4. 需求变更应对方法 161 4.1.5 项目实施方案 163 4.1.5.1. 实施计划日程表 165 4.1.5.2. 实施计划表 166 4.1.5.3. 阶段工作及成果 168 4.1.5.4. 项目进度保障措施与办法 170 1. 定义项目成功的标准 170 2. 识别项目的驱动、约束和自由程度 171 3. 定义产品发布标准 171 4. 沟通承诺 171 5. 计划中,在质量控制活动后应该有修改工作 171 6. 为过程改进安排时间 172 7. 管理项目的风险 172 8. 根据工作计划而不是日历来作估计 172 9. 不要为人员安排超过他们80%的时间 172 10. 记录你的估算和你是如何达到估算的 173 11. 记录估算并且使用估算工具 173 12. 遵守学习曲线 173 13. 考虑意外缓冲 173 14. 录实际情况与估算情况 173 15. 只有当任务100%完成时,才认为该任务完成 174 16. 公开、公正地跟踪项目状态 174 4.1.6 质量控制、质量保证方案 175 4.1.6.1. 项目质量管理的关键 175 4.1.6.2. 本项目质量保证措施 175 4.1.6.3. IT项目质量管理的目标和质量控制 177 4.1.7 系统安全性方案 179 4.1.7.1. 安全性设计原则 179 (9) 系统对内网服务及对外网服务功能要求独立发布,并提供安全、可靠的权限控制。 179 4.1.7.2. 服务器安全 179 4.1.7.3. 移动应用安全 179 4.1.7.4. 终端认证 180 4.1.7.5. 终端授权 181 4.1.7.6. 终端证书 181 4.1.7.7. 本地安全存储 181 4.1.7.8. 数据传输安全 181 4.1.7.9. 数据库安全机制 182 4.1.7.10. 容错机制 182 4.1.7.11. 数据同步 183 4.1.7.12. 服务器集群和负载均衡 183 4.1.7.13. 防火墙 184 4.1.8 项目交付定义 185 4.1.9 项目验收方案 186 4.1.9.1. 验收方案 186 1. 验收目的 186 2. 验收对象 186 3. 项目验收的前提条件 186 (1) 所有建设项目按照合同要求全部建成,并满足使用要求; 186 4. 验收方法 187 5. 验收步骤 187 6. 验收程序 188 7. 验收依据 189 8. 验收内容和标准 190 9. 验收结论 191 10. 项目交接 192 4.1.9.2. 测试方案 193 4.1.9.2.1. 测试内容设计 193 4.1.9.2.2. 测试阶段规划 198 V模型图 198 4.1.9.2.3. 测试工作流程 201 4.1.9.2.4. 测试结果评价与测试工具 208 (1) 项目汇报文件 210 (2) 测试方案 210 4.1.9.2.5. 测试人员名单 211 4.1.10 本期项目完成交付后,技术服务计划、维护、承诺及费用 212 4.1.10.1. 概述 212 4.1.10.2. 服务内容 213 1. 咨询服务 213 2. 应用系统的故障响应 213 3. 应用系统辅助操作 213 4. 应用系统的维护服务 213 5. 交流和培训 213 6. 应用系统业务调整 214 7. 应用系统软件升级 214 4.1.10.3. 支持机构 214 1. 咨询服务组 214 2. 咨询服务专家组 214 4.1.10.4. 支持方式 215 1. 现场维护 215 2. 热线电话咨询 215 3. 咨询服务网站 215 (1) 远程登录诊断维护 215 4.1.11 人员培训计划、技术移方案 216 4.1.11.1. 培训方案 216 4.1.11.1.1. 培训对象和内容 216 4.1.11.1.2. 培训目的 217 4.1.11.1.3. 培训原则与培训质量保证体系 218 (1) 培训的师资力量 219 4.1.11.1.4. 培训方式 220 4.1.11.1.5. 培训大纲 220 4.1.11.1.6. 培训组织及技术力量安排 222 4.1.11.1.7. 培训组织方案 223 4.1.11.2. 技术移方案 225 4.1.12 预期系统性能状况,后续升级扩展方案和计划建议 227 4.1.12.1. 移动端响应标准 227 4.1.12.2. 系统响应标准 227 4.1.12.3. 优化办法 227 4.1.12.4. 系统批处理效率 228 4.1.12.5. 并发用户下的系统性能 228 4.1.13 其他资料 229 4.1.13.1. 典型案例 229
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值