待软件需求discover阶段完成,也就是可行性研究完成,公司决_程序开发编程(软件需求体会---define阶段)

开发技术指南» 文章正文

引言：待软件需求discover阶段完成,也就是可行性研究完成,公司决

·bugzero的安装过程、tomcat与oracle xdb端口冲突的处理(ora-01041的解决) »显示摘要«

摘要：记录bugzero的安装过程(很零乱，备查的)：操作系统为mandrake8.1web server为tomcat 5.0.18 1.修改tomcat配置文件在tomcat-5.0.18/conf/server.xml中增加<context path="bugzero" docbase="/usr/local/bugzero" debug="" /> 2.创建 bugzero的......

·读《敏捷建模》是看到的一段文字，深有感触，摘抄下来 »显示摘要«

摘要：在书中270页有权力的催着要纸的人在比较大型的的组织机构里，这样的it专家是很普遍的：他们已经有好几年的时间没有直接参与国软件开发了－编程、建模、测试或管理。这些人通常担任基础设施服务的角色，例如软件过程管理，复用管理或者程序管理，并且经过了一段时间他们的角色已经退化到了这样的地步：他们工作的中心就是“催纸”。这些人通常要求个人或团队提供进度报告，由他们进行检查并提供反馈；举行进度会议以便他们能知道项目进展的如果；要求项目团队提供......

软件需求体会---define阶段

待软件需求discover阶段完成,也就是可行性研究完成,公司决定进行该项目/产品的开

1)分析项目的风险,编写项目风险控制报告.在国内,这个报告相当于一个摆设,文档写【相关文章:FreeBSD kernel 编译大法(】

发后,就进入了软件需求的define阶段.define阶段包括下面的事情: 【扩展阅读:收集并存储性能监控器数据到SQL Ser】

是money&money. 【扩展信息:走进C# （我的C#学习之旅）之一】

完就放那里了;为什么呢,因为控制风险需要成本,国内老总不想要成本,老总想要的只

2)明确项目的功能需求,整理项目的需求文档.

功能需求文档可能不只一个,可能每个子系统都有单独的需求文档;不确定的功能需求

应该用tbd来标志;功能需求文档可能包括数据字典.功能需求应该由项目的开发经理整

理,但我参与的项目,需求文档都是由小兵来完成的,呵呵,因为功能需求文档太琐碎了,

当官的才不做这种没有成就感的小事.当然了,有的项目的功能需求文档是要用户签字

的,这样的文档公司会比较注意.

3)建立需求跟踪矩阵(scope matrix)

需求跟踪矩阵(scope matrix)应该是由项目的开发经理来完成并跟踪的,在我开始做软

件时,有个资深的程序员坚定不移地告诉我,需求跟踪矩阵(scope matrix)是由项目的

配置管理人员来做,害了我好一阵子;后来想想,需求跟踪矩阵(scope matrix)将要指导

后期开发,所以编写人员还应该是开发经理.

4)功能需求的评审

功能需求的评审应该由项目经理发起,行业专家与客户参与,通过会议形式讨论,得出

review notes.

·程序备忘录：之六－判定树的用法(2004/08/23 20:06) »显示摘要«

摘要：　　软件理论很多很杂，而且有很多是借鉴了其它专业的理论。从软件工程的瀑布模型中知道，编码要依据详细设计来完成。判定树是系统分析和设计期的工具，但编码人员不一定每次都能从详细设计书中找到明确的判定树资料。　　假定有下面的编码需求：有两个状态变量，每个变量有4种状态值，对两个状态的不同组合共有4种处理方式。可以进行下面的编码(java例)。 //--------------------------------------------------------- ......

» 本期热门文章：

· 热门栏目：

» 相关精选文章

» 其它相关：