软件开发管理

从网上搜索到网友整理的软件开发管理中应用到的一些文档,感觉对日常工作帮助很大,本着传播和共享的精神,转帖于下:如有侵犯,请告知:

同时感谢提供存放空间,请依链接下载!

收集了一些关于软件开发中需要用到的规范文档,软件需求分析报告、详细设计说明、概要设计说明等等,包含国家标准文档、东软的、RUP模板。每个软件公司一般都有自己内部的一些文档规范,项目管理规范、制度等规范,这些可作为参考使用。

有4部分文档:

一、国标文档:(下载

可行性研究报告(GB8567——88).doc (86K)
图1.doc (26K)
开发进度月报(GB8567——88).doc (24K)
操作手册(GB8567——88).doc (45K)
数据库设计说明书(GB8567——88).doc (36K)
数据要求说明书(GB856T——88).doc (34K)
文件给制实施规定的实例(GB8567-88).doc (59K)
概要设计说明书(GB8567——88).doc (47K)
模块开发卷宗(GB8567——88).doc (20K)
测试分析报告(GB8567——88).doc (24K)
测试计划(GB8567——88).doc (26K)
用户手册(GB8567——88).doc (58K)
详细设计说明书(GB8567——88).doc (40K)
软件需求说明书/软件需求分析报告/软件功能规格说明书(GB856T——88).doc (45K)
项目开发总结报告(GB8567——88).doc (26K)
项目开发计划(GB856T——88).doc (47K)

二、东软规范文档(下载

交付与安装.doc (192K)
产品制作规定.doc (232K)
产品策划及可行性分析.doc (193K)
人员考评管理规范.doc (354K)
信息管理.doc (90K)
内审员评定及授权规范.doc (199K)
内部质量体系审核.doc (82K)
分包供方评定规范.doc (214K)
可行性分析报告编写规范.doc (229K)
合同制定规范.doc (237K)
合同评审.doc (224K)
培训管理.doc (54K)
培训管理规范.doc (195K)
客户培训管理规范.doc (218K)
客户服务管理.doc (82K)
客户满意度的测量.doc (169K)
客户问题受理规范.doc (113K)
客户验收.doc (76K)
库房管理规定.doc (218K)
度量.doc (104K)
开发计划编写规范.doc (203K)
技术报告编写规范.doc (74K)
招聘与就职管理规范.doc (274K)
文件归档与编目指导书.doc (76K)
文件管理.doc (203K)
文件编写导则.doc (180K)
文件编号规定.doc (79K)
服务合同制定规范.doc (278K)
服务合同评审规范.doc (203K)
标书制定规范.doc (220K)
标书评审.doc (135K)
标识规范.doc (450K)
档案管理规定.doc (90K)
测试工作总结编写规范.doc (132K)
测试用例标准.doc (93K)
测试计划编写规范.doc (110K)
用户手册编制规范.doc (482K)
管理评审.doc (39K)
系统设计报告编写规范.doc (200K)
纠正和预防措施.doc (50K)
维护管理.doc (90K)
计算机源代码编写规范.doc (102K)
设备和工具管理.doc (49K)
设备管理规定.doc (334K)
设备维护规定.doc (62K)
设计和实现.doc (128K)
质量手册.doc (339K)
质量策划.doc (105K)
质量计划制定规范.doc (106K)
质量记录管理.doc (56K)
软件产品释放.doc (150K)
软件功能规格说明书编写规范.doc (207K)
软件测试.doc (143K)
软件质量保证.doc (196K)
配套的产品管理.doc (138K)
配置管理.doc (91K)
配置管理规范.doc (125K)
配置管理计划编写规范.doc (175K)
采购.doc (184K)
采购供方评定办法.doc (172K)
采购流程管理.doc (212K)
采购设备验收规定.doc (237K)
需求分析.doc (156K)
需求分析报告编写规范.doc (237K)
项目分包管理规范.doc (109K)
项目总结报告编写规范.doc (223K)
项目策划..doc (198K)

三、RUP模板(下载

a_and_d
-----Use-Case-用例实现规约.dot (39K)
-----vssver.scc (0K)
-----软件构架文档.dot (47K)
bm
-----vssver.scc (0K)
-----业务前景.dot (68K)
-----业务构架文档.dot (48K)
-----业务用例实现规约.dot (40K)
-----业务用例规约.dot (48K)
-----业务规则.dot (44K)
-----业务词汇表.dot (42K)
-----目标组织评估.dot (47K)
-----补充业务规约.dot (42K)
cm_mgt
-----vssver.scc (0K)
-----配置管理计划.dot (49K)
deploy
-----vssver.scc (0K)
-----发布版本说明.dot (50K)
-----材料清单.dot (44K)
-----部署计划.dot (48K)
environ
-----vssver.scc (0K)
-----业务建模指南.dot (131K)
-----开发案例.dot (187K)
-----开发组织评估.dot (67K)
-----测试指南.dot (153K)
-----用例建模指南.dot (104K)
-----编程指南.dot (138K)
-----设计指南.dot (144K)
impl
-----vssver.scc (0K)
-----集成构建计划.dot (40K)
mgmnt
-----vssver.scc (0K)
-----产品验收计划.dot (118K)
-----商业理由.dot (96K)
-----状态评估.dot (78K)
-----评测计划.dot (83K)
-----质量保证计划.dot (130K)
-----软件开发计划.dot (96K)
-----迭代计划.dot (63K)
-----迭代评估.dot (97K)
-----问题解决计划.dot (102K)
-----风险列表.dot (80K)
-----风险管理计划.dot (93K)
req
-----vssver.scc (0K)
-----前景.dot (83K)
-----涉众请求.dot (54K)
-----用例实现规约.dot (70K)
-----补充规约.dot (80K)
-----词汇表.dot (67K)
-----软件需求规约.dot (58K)
-----软件需求规约子系统或特性.dot (45K)
-----需求管理计划.dot (52K)
test
-----vssver.scc (0K)
-----测试计划.dot (128K)
-----测试评估摘要.dot (41K)

四、常用文档(下载

Project_Good
-----1.任务申请.doc (33K)
-----2.可行性与计划阶段--可行性研究报告.doc (208K)
-----2.可行性与计划阶段--项目开发计划.doc (45K)
-----3.需求分析阶段--数据要求说明书.doc (43K)
-----3.需求分析阶段--用户手册概要.doc (48K)
-----3.需求分析阶段--需求说明书.doc (50K)
-----4.概要设计阶段--数据库设计说明书.doc (43K)
-----4.概要设计阶段--概要设计说明书的.doc (139K)
-----4.概要设计阶段--组装测试计划.doc (61K)
-----5.详细设计阶段--详细设计说明书.doc (51K)
-----6.实现阶段--模块开发说明.doc (41K)
-----7.单元测试阶段--单元测试报告.doc (33K)



[本日志由 achely 于 2007-11-25 08:19 PM 编辑]

bwlee 于 2008-05-29

看得见的软件开发管理---缺陷管理

10-16

摘要:如果一个项目的每个步骤实实在在的眼皮底下进行,而且随时可以翻阅,那么这个项目的成功一定不会远了。开发过程的管理也是这样,控制每一个细节,水到渠成。rnrn关键字:缺陷管理 免费 任务管理rn最近陪家人逛了几集电视连续剧《情迷天使》和《玉观音》,《玉观音》算是重播了,只是以前也没注意,现在看了几集,真是看不下去了,其中给我最大的感受就是一群人,一时的冲动,种下恶果,然后前方百计的企图改变或是掩盖这个结果,苦苦挣扎着。既然希望有个严肃的结果,行为就一定要严谨。那么是否行为严谨就一定能有严肃的结果。 rn由此我一直在想着,行为决定结果的问题,也想着这其中和软件开发管理之间存在的紧密关系。任何一个项目,就算是最资深的开发组长,最团结优秀的开发团队,也不能保证开发过程一定能按计划完全顺利进行,更别说放任计划随意进行的开发了(实际上这样进行开发的项目很多)。这根源到底是什么呢?我想说的就是可控性,如何实现可控性,是项目计划工具—Microsoft Project 2002,是软件开发管理工具—美国Intersolv 公司的PVCS,是软件配置管理工具—ClearCase, 是画出优美项目周期的Viso,不,都不是,各位别见笑,我并没有看轻它们的意思,这些都是举世之作,不是我狂妄的地方。之所以说不是,是因为这完全是两码子事,它们进行的是宏观的调控,不够细分,控制不到细节。结果是由每个细节的过程来决定的,要控制项目就要控制到每个开发的细节,所以今天要说的是微软的开发管理理念之一—BMS 缺陷管理理念(这里说的是广义的缺陷管理) 好好了解如何运用这个理念和工具真正掌控细节,从而实现开发的最优路径。rn(一)BMS 缺陷管理的作用rn保持进度、保证质量rn我们都知道,管理的目标是争取让每个事情都能按时完成并保证质量,使“客户满意、公司获利”,其实还有一个当然就是“员工受益”,通过软件开发管理提高,提高软件质量,创造效益,最终达到大家满意。rn(二)BMS 缺陷管理如何运作rn1、如何保持进度rn缺陷管理理念讲究的是将工作细分成小模块甚至是最小的单元,列出要完成的模块,每个模块工作安排具体还细分到要完成的每个步骤,具体分配到人。比如软件项目中的一个小模块就可以分成:需求(或bug)、指派、开发、测试、构造、验收、发布。项目主管可以把每个小模块分配到开发组长,开发组长可以继续指派到每个开发人员手中,开发中的每个人都有他对应的位置,每个人都可以轻松看到他在每个模块中的任务内容及时间安排。主管也很容易了解到每个人完成的情况,从而可以随时修正方向,及时调整工作安排,保持项目不偏不离继续按计划进行。这也就是缺陷管理真正的精髓:将原来隐含的关系变成清晰的、易于管理的关系,使项目开发更有计划和有效地运行。rn2、如何保证质量rn既然要让工作具有质量,那么就要极力预防错误的发生,就算发生了,也要能及早发现,及时修正。缺陷管理的理念就是每个环节都有相对应的人员在进行稽核,一直循环,直到达到要求为止,每个开发人员分别完成自己的功能,针对要修改的任务进行修改,每个测试人员针对可测试的功能进行测试,测试不合格,再重新返回修改。把bug扼杀在交给客户使用之前。我们知道开发过程中,bug越迟清除,时间花得越多,立刻除虫,时间是节省最多的(既然有时间还不如听听音乐,侃侃大山),也不用到后面弄得浑身乏术,筋疲力尽,连对开发软件的兴趣都没了。甚至还被客户投诉,连奖金都没了。rn3、管理文档rn开发中还经常出现的就是项目组把工作进度报告看成是一种很重的负担,要么写不出来,要么要花很多时间去写,为什么要特别说很重的,因为负担都是有的,但还是要写,没办法,可是如果每天要花3~4个小时写报告,正常的开发工作却不得不加班做,那么就要想想办法了,毕竟我们是做项目的,不是写报告的。缺陷管理的理念就是清楚的纪录每个问题的过程状态,中间产生的文档可以通过系统随时记录在案,最高效率产生文档,一目了然,完成哪些模块,更正哪些问题,基本上报告也就写完了。文档的管理还有另一个好处就是容易翻阅历史资料,减少内耗和误差,这点大家体会应该也很深,因为很多细节的部分,是不会记录在案的,当时为什么要这样做,那样改,由谁改,全凭脑袋记忆,无从查证,运用BMS缺陷管理,可以轻松解决这一点困扰。rn(三)如何选用工具进行缺陷管理rn开发管理过程不是操作复杂,就说明管理就是好;也不是稿纸写一写,会议开一开,就可以。最关键的是适合,看得见,管得着(不是管人哦,注意是管事)。如何跟踪,自然靠的就是软件,那么就稍微介绍一下国外已经非常流行、国内刚开始的缺陷管理工具。现在网上可以查得到的缺陷管理软件大部分是英文版的,也有2~3个是中文版的,有要收费的,有免费提供的。但无论如何,比较好的缺陷管理系统应该具备下列的优点rn1、 安装简易,操作简易rn2、 支持开发、构建、测试、验收多重迭代rn3、 支持项目经理全程追踪督促rn4、 支持开发组长、测试组长多级指派rn5、 完整的追踪信息展现rn6、 支持发布版本的缺陷关联rn7、 Mail实时通知缺陷任务rn有了先进的缺陷管理理念和一套好的缺陷管理系统,相信项目组长,开发组长,都可以很轻松的控制整个开发的进度,时刻了解开发的进度,保证开发的质量,交出满意的工作清单。rnrn

没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试