本问主要分析了一个软件过程,并且使用现有的科技进行控制。
涉及到的技术包括:notebook / wiki / schedular / testdrivens / versions / bugtrace / feedback,整个又称为project。
整个过程又使用了messageflow架构进行全程协助,使用search engine进行数据维护。
notebook 思路流水账
有什么写什么,可以根据发帖进行跟帖讨论。流水账。
wiki 对外展示和内部查询的正规项目文档
public部分:项目介绍、需求文档、技术文档、其他说明文档(操作说明等)
private部分:部署文档、相关协议、架构文档、API文档、数据库设计文档
schedular 任务列表
既有简单的个人任务,也有团队的任务调度。如meeting、todo等
testdrivens 测试驱动
测试用例、回归测试等。包括了
。针对class级别的function test
。针对framework的unit test
。针对application的overal test
。针对UI的UI test
versions 版本控制
当前的版本,历史版本
当前dll的依赖项目
某个方法的被依赖情况,本dll细化到公共类的公共方法;被依赖细化到:项目、DLL
bugtraces 错误跟踪
与log系统结合,自动收集日志系统发放的bug情况。
与version结合,跟踪到版本的错误情况
feedback 顾客反馈
项目部署并且稳定之后,接受顾客的建议、二次开发、功能点等,类似notebook,只是职责上有差别。
project 项目
以上所有技术的总框架页面。项目之间有继承关系(可以参考OO的思路,如何通过继承去实现文档的方便编辑)
新建项目流程规范
1. 想法阶段:使用notebook跟踪思路,和合作者沟通,非正规合作。
2. 实施阶段:由notebook生成新的project(包含当前的活动点 activity ),输入项目的目的(完成什么)、需要依赖的技术(前提条件)、大概耗时(计划)。同时project将生成对应的bugtraces、feedback等相关的链接。
3. 开发阶段:本地部署项目文件;使用version设置好版本;配置好API读取、版本读取; 开发中不断准备相关的文档素材。
4. 测试阶段:使用自动化技术编写测试代码,并同步到网站,进行测试并规范测试用例。
5. 发布阶段:完善各种文档;配置更新、bug跟踪等。
修正bug(revision)流程规范
1. 根据顾客的反馈、系统的bug日志编写bugtraces
2. 根据bug的级别进行修复,基本原则:不能够修改对外的接口、方法,不能够产生额外影响为目的去修复。
3. 修正后,进入测试阶段,自动化测试功能点、根据API的依赖关系测试依赖点、包括回归测试、稳定性测试。
4. 使用版本控制的发布机制,发布最新的文件到客户端。
新增功能点(function point)流程规范
1. 在notebook上分析新功能点、受影响的范围、开发时间计划。
2. 在原来的project基础上,添加对应的信息;同时添加一个新的活动点(activity)。
3. 回到新建项目流程进行开发。部署
提升版本(major version)流程规范
1. 在notebook上分析新功能点、受影响的范围、开发时间计划。
2. notebook新增一个project,原project处于关闭状态,同时原project保存了当前最新的版本信息、文件等。
3. 回到新建项目流程进行开发。部署
其他流程简介
1. 顾客反馈通过feedback直接与开发人员沟通
2. 开发人员会不断维护wiki,创建各种说明书文档,让顾客下载打印
3. 外部人员通过首页的查询可以了解到wiki的公开部分
4. 内部人员登录一次后,能够了解到对应到需要的API、依赖分析等。
5. notebook过程中使用messageflow产生brain storm
6. 开发过程中使用schedular进行团队协作
其他相关约束简介
1. 使用任何第三方的软件等,必须经过严格的审核!例如dotfuscator的问题等等。非常严重!