我就像问问这几大项下面还有什么分支么？都分别用到什么工具（比如什么图形工具之类的）？还有就是都分别要写那些文档？
先多谢前辈们啦...
16 个解决方案
#1
你问的这个问题够写若干本书的
#2
简单说说就行了，就给我入个门吧
#3
我也看了一些书了，
但还是想听听有经验的前辈们是怎么在这些阶段应用工具的和编写文档的
但还是想听听有经验的前辈们是怎么在这些阶段应用工具的和编写文档的
#4
不同的流派，所用工具及重点是不一样的。
#5
帮你顶下，我也入行不久。
#6
你少了一个关键的过程，就是系统规划前面的需求分析，如果再细点的话，前面还有可行性分析。一般来系统规划这个过程好象不是很常用，我这是第一次听说。
一般出口的文档有，可行性分析报告，需求文档，需求规格说明（需求文档的进化，需求文档是对用户业务的描述和简单分析，需求规格说明中加了一些重要的类的提取，业务用例的提取和说明，一些关键的活动描述，这时需要用到UML工具画活动图，提取类，画类图等），之后是面向对象的分析和设计文档（通常在OO的过程中不叫系统分析和系统设计，而叫OOA和OOD，或OOAD，面向对象的分析和设计，这个过程主要工具就是UML工具，类图，活动图，用例图，序列图，状态图，包图等，可根据项目需要而取舍），再来就是开发了，工具就不用我说了吧。再次就是实施和维护了。
另外测试并不是一个单一环节，它是贯穿整个开发过程的，从需求的描述开始，测试就应该开始了，但不是对代码的测试，而是制作测试用例，并且需要及时发现需求文档的问题，帮助分析人员在前期就减少BUG的可能，设计过程中也离不开测试，道理一样。
你据说的大过程下的小项，实在太多了，每个都可以细分好多，便做便学吧。
一般出口的文档有，可行性分析报告，需求文档，需求规格说明（需求文档的进化，需求文档是对用户业务的描述和简单分析，需求规格说明中加了一些重要的类的提取，业务用例的提取和说明，一些关键的活动描述，这时需要用到UML工具画活动图，提取类，画类图等），之后是面向对象的分析和设计文档（通常在OO的过程中不叫系统分析和系统设计，而叫OOA和OOD，或OOAD，面向对象的分析和设计，这个过程主要工具就是UML工具，类图，活动图，用例图，序列图，状态图，包图等，可根据项目需要而取舍），再来就是开发了，工具就不用我说了吧。再次就是实施和维护了。
另外测试并不是一个单一环节，它是贯穿整个开发过程的，从需求的描述开始，测试就应该开始了，但不是对代码的测试，而是制作测试用例，并且需要及时发现需求文档的问题，帮助分析人员在前期就减少BUG的可能，设计过程中也离不开测试，道理一样。
你据说的大过程下的小项，实在太多了，每个都可以细分好多，便做便学吧。
#7
前面打错了，
一般出口的文档有 改为 一般出品的文档有
一般出口的文档有 改为 一般出品的文档有
#8
xiexie
#9
一般来说刚刚这位仁兄对瀑布模型的描述石没有错的，但是好需要补充一下：
系统的开发维护是一个V字型的过程，一般从需求分析开始，到系统退役结束。从开放方的角度来看到验收测试结束，后续的系统扩展可以重新立项。
需求分析（含可行性分析） 验收测试
总体设计 产品评估和市场定位
功能和性能设计 系统功能和性能测试
详细设计 集成和模块测试
编码和自测
各个工作任务的产品和输出
需求分析：
SRS（软件需求规格书）
可行性分析报告
签订《用户需求确认书》
签订合同书
总体设计：
项目设计方案
选定技术平台
设定项目目标
以期进一步和客户达成一致
功能和性能设计：
功能说明书（各个功能和处理描述）
软件非功能方面的技术指标描述
用户确认函等用户认可的东西（不要强求，以免客户收到压力）
详细设计：
系统数据结构
系统架构
技术实现等文档
编码自测：
程序源代码
集成测试：
各模块功能和性能磨合测试方法、计划和测试记录
系统测试：
系统从各个模块构架成功后的测试
含功能测试、性能测试等
产品评估和市场定位：
产品评估数据汇总
产品评估结果
项目总结（项目过程的得失、经验、人员成长情况等对组织有利的东西）
需求方对产品的验收和付款等：
产品验收书
产品问题汇总
可能又有需求变更
系统的开发维护是一个V字型的过程，一般从需求分析开始，到系统退役结束。从开放方的角度来看到验收测试结束，后续的系统扩展可以重新立项。
需求分析（含可行性分析） 验收测试
总体设计 产品评估和市场定位
功能和性能设计 系统功能和性能测试
详细设计 集成和模块测试
编码和自测
各个工作任务的产品和输出
需求分析：
SRS（软件需求规格书）
可行性分析报告
签订《用户需求确认书》
签订合同书
总体设计：
项目设计方案
选定技术平台
设定项目目标
以期进一步和客户达成一致
功能和性能设计：
功能说明书（各个功能和处理描述）
软件非功能方面的技术指标描述
用户确认函等用户认可的东西（不要强求，以免客户收到压力）
详细设计：
系统数据结构
系统架构
技术实现等文档
编码自测：
程序源代码
集成测试：
各模块功能和性能磨合测试方法、计划和测试记录
系统测试：
系统从各个模块构架成功后的测试
含功能测试、性能测试等
产品评估和市场定位：
产品评估数据汇总
产品评估结果
项目总结（项目过程的得失、经验、人员成长情况等对组织有利的东西）
需求方对产品的验收和付款等：
产品验收书
产品问题汇总
可能又有需求变更
#10
累死了，打字打到手发麻！
期待下一代项目管理人才的出炉！
我们好像还真没有给中国做出有竞争性的项目，仅供糊口用了！
回想就觉得愧对祖国！
期待下一代项目管理人才的出炉！
我们好像还真没有给中国做出有竞争性的项目，仅供糊口用了！
回想就觉得愧对祖国！
#11
推荐一本书《系统分析师常用工具》中讲有各阶段的工具。《软件开发项目管理》一书讲有各阶段产生的工作（文档）。
#12
用到什么工具也和软件工程的流派有关系。比如RUP讲究用Rational Rose.
和公司预算有关系：需求管理有钱的可以买DOORS,没钱的用Microsoft Word、Excel:-)
和公司预算有关系：需求管理有钱的可以买DOORS,没钱的用Microsoft Word、Excel:-)
#13
该回复被版主删除
#14
建议楼主先去关注一下:RUP,MSF,敏捷
________________________________
专业路过,友情UP
________________________________
专业路过,友情UP
#15
luyingchuan,在中国好象不需要那么多文档,
#16
一堆散乱的文档并不能真正的起到作用
要说软件的生命周期，可以参考IEEE的标准
至于文档，关键是要反映系统的真实性，自己做系统，不是拿来给别人审查的
另外文档必须有评审，否则效果很差，只有大家参与了评审，才会对文档的内容有深入的理解
unow2005.tianyablog.com
要说软件的生命周期，可以参考IEEE的标准
至于文档，关键是要反映系统的真实性，自己做系统，不是拿来给别人审查的
另外文档必须有评审，否则效果很差，只有大家参与了评审，才会对文档的内容有深入的理解
unow2005.tianyablog.com
#17
mark
#1
你问的这个问题够写若干本书的
#2
简单说说就行了，就给我入个门吧
#3
我也看了一些书了，
但还是想听听有经验的前辈们是怎么在这些阶段应用工具的和编写文档的
但还是想听听有经验的前辈们是怎么在这些阶段应用工具的和编写文档的
#4
不同的流派，所用工具及重点是不一样的。
#5
帮你顶下，我也入行不久。
#6
你少了一个关键的过程，就是系统规划前面的需求分析，如果再细点的话，前面还有可行性分析。一般来系统规划这个过程好象不是很常用，我这是第一次听说。
一般出口的文档有，可行性分析报告，需求文档，需求规格说明（需求文档的进化，需求文档是对用户业务的描述和简单分析，需求规格说明中加了一些重要的类的提取，业务用例的提取和说明，一些关键的活动描述，这时需要用到UML工具画活动图，提取类，画类图等），之后是面向对象的分析和设计文档（通常在OO的过程中不叫系统分析和系统设计，而叫OOA和OOD，或OOAD，面向对象的分析和设计，这个过程主要工具就是UML工具，类图，活动图，用例图，序列图，状态图，包图等，可根据项目需要而取舍），再来就是开发了，工具就不用我说了吧。再次就是实施和维护了。
另外测试并不是一个单一环节，它是贯穿整个开发过程的，从需求的描述开始，测试就应该开始了，但不是对代码的测试，而是制作测试用例，并且需要及时发现需求文档的问题，帮助分析人员在前期就减少BUG的可能，设计过程中也离不开测试，道理一样。
你据说的大过程下的小项，实在太多了，每个都可以细分好多，便做便学吧。
一般出口的文档有，可行性分析报告，需求文档，需求规格说明（需求文档的进化，需求文档是对用户业务的描述和简单分析，需求规格说明中加了一些重要的类的提取，业务用例的提取和说明，一些关键的活动描述，这时需要用到UML工具画活动图，提取类，画类图等），之后是面向对象的分析和设计文档（通常在OO的过程中不叫系统分析和系统设计，而叫OOA和OOD，或OOAD，面向对象的分析和设计，这个过程主要工具就是UML工具，类图，活动图，用例图，序列图，状态图，包图等，可根据项目需要而取舍），再来就是开发了，工具就不用我说了吧。再次就是实施和维护了。
另外测试并不是一个单一环节，它是贯穿整个开发过程的，从需求的描述开始，测试就应该开始了，但不是对代码的测试，而是制作测试用例，并且需要及时发现需求文档的问题，帮助分析人员在前期就减少BUG的可能，设计过程中也离不开测试，道理一样。
你据说的大过程下的小项，实在太多了，每个都可以细分好多，便做便学吧。
#7
前面打错了，
一般出口的文档有 改为 一般出品的文档有
一般出口的文档有 改为 一般出品的文档有
#8
xiexie
#9
一般来说刚刚这位仁兄对瀑布模型的描述石没有错的，但是好需要补充一下：
系统的开发维护是一个V字型的过程，一般从需求分析开始，到系统退役结束。从开放方的角度来看到验收测试结束，后续的系统扩展可以重新立项。
需求分析（含可行性分析） 验收测试
总体设计 产品评估和市场定位
功能和性能设计 系统功能和性能测试
详细设计 集成和模块测试
编码和自测
各个工作任务的产品和输出
需求分析：
SRS（软件需求规格书）
可行性分析报告
签订《用户需求确认书》
签订合同书
总体设计：
项目设计方案
选定技术平台
设定项目目标
以期进一步和客户达成一致
功能和性能设计：
功能说明书（各个功能和处理描述）
软件非功能方面的技术指标描述
用户确认函等用户认可的东西（不要强求，以免客户收到压力）
详细设计：
系统数据结构
系统架构
技术实现等文档
编码自测：
程序源代码
集成测试：
各模块功能和性能磨合测试方法、计划和测试记录
系统测试：
系统从各个模块构架成功后的测试
含功能测试、性能测试等
产品评估和市场定位：
产品评估数据汇总
产品评估结果
项目总结（项目过程的得失、经验、人员成长情况等对组织有利的东西）
需求方对产品的验收和付款等：
产品验收书
产品问题汇总
可能又有需求变更
系统的开发维护是一个V字型的过程，一般从需求分析开始，到系统退役结束。从开放方的角度来看到验收测试结束，后续的系统扩展可以重新立项。
需求分析（含可行性分析） 验收测试
总体设计 产品评估和市场定位
功能和性能设计 系统功能和性能测试
详细设计 集成和模块测试
编码和自测
各个工作任务的产品和输出
需求分析：
SRS（软件需求规格书）
可行性分析报告
签订《用户需求确认书》
签订合同书
总体设计：
项目设计方案
选定技术平台
设定项目目标
以期进一步和客户达成一致
功能和性能设计：
功能说明书（各个功能和处理描述）
软件非功能方面的技术指标描述
用户确认函等用户认可的东西（不要强求，以免客户收到压力）
详细设计：
系统数据结构
系统架构
技术实现等文档
编码自测：
程序源代码
集成测试：
各模块功能和性能磨合测试方法、计划和测试记录
系统测试：
系统从各个模块构架成功后的测试
含功能测试、性能测试等
产品评估和市场定位：
产品评估数据汇总
产品评估结果
项目总结（项目过程的得失、经验、人员成长情况等对组织有利的东西）
需求方对产品的验收和付款等：
产品验收书
产品问题汇总
可能又有需求变更
#10
累死了，打字打到手发麻！
期待下一代项目管理人才的出炉！
我们好像还真没有给中国做出有竞争性的项目，仅供糊口用了！
回想就觉得愧对祖国！
期待下一代项目管理人才的出炉！
我们好像还真没有给中国做出有竞争性的项目，仅供糊口用了！
回想就觉得愧对祖国！
#11
推荐一本书《系统分析师常用工具》中讲有各阶段的工具。《软件开发项目管理》一书讲有各阶段产生的工作（文档）。
#12
用到什么工具也和软件工程的流派有关系。比如RUP讲究用Rational Rose.
和公司预算有关系：需求管理有钱的可以买DOORS,没钱的用Microsoft Word、Excel:-)
和公司预算有关系：需求管理有钱的可以买DOORS,没钱的用Microsoft Word、Excel:-)
#13
该回复被版主删除
#14
建议楼主先去关注一下:RUP,MSF,敏捷
________________________________
专业路过,友情UP
________________________________
专业路过,友情UP
#15
luyingchuan,在中国好象不需要那么多文档,
#16
一堆散乱的文档并不能真正的起到作用
要说软件的生命周期，可以参考IEEE的标准
至于文档，关键是要反映系统的真实性，自己做系统，不是拿来给别人审查的
另外文档必须有评审，否则效果很差，只有大家参与了评审，才会对文档的内容有深入的理解
unow2005.tianyablog.com
要说软件的生命周期，可以参考IEEE的标准
至于文档，关键是要反映系统的真实性，自己做系统，不是拿来给别人审查的
另外文档必须有评审，否则效果很差，只有大家参与了评审，才会对文档的内容有深入的理解
unow2005.tianyablog.com
#17
mark