|
|
以下为几年前，胡乱写下的零碎想法。现在翻回来看，还是觉得有些问题没找到答案。抛砖引玉，大家是否也说说你们的经历和经验？！[/COLOR]
93-99年,那时,软件中心所有的项目,几乎没有文档化,-----
2000-至今,开始引入ISO9000,制订一套标准.流程,模板--------要求所有的人: “将自己的所做文档化”
今天 ,我们的文档柜开始有些积累,但是,我们也同时发现了它带来的必然副产品-----我们让项目组的骨干,浪费在大量无用的文档工作中
以前,我在写这些文档时，一般我会清楚：哪些是为了应付工委会评审?哪些是为了应付产品控制部的?哪些是为了给自己将来维护\给组员看的?-----------对于提交给工委会和产品部的文档通常最终消失在他们的桌面上或者文件柜里,因为没有人再去查阅!而往往只有本来写给自己或组员看的文档才是真正有价值的.
我们大可不必去对工委会,产品部发牢骚.想想这是企业发展的比经之路,CMM不同阶段的思想,工作中心很值得我们参考:
CMM/2,工作重心:文档化,流程化;
CMM/3, 工作重心:过程数据量化;
CMM/4,CMM/5, 工作重心:流程改进,流程精简
任何事物发展都需要一个过程.
如果,2年前,我们跟产品部发牢骚: “你的模板,我用起来很别扭” “需求规格书与详细设计书有很多重叠,很多无谓工作”,PP, “我都快繁死了,现在我只想你们多写文档,然后把文档提交给我,现在,一切按标准来执行”----------那时我的工资不到4000,我在想: “哪一天,我的工资到10000,老周你是否还敢白养我?”
我们的总经理室,有两种选择:
把我解雇;(剩下10000,再去请4000的);
改革流程,提高效益
所以, ,为了饭碗, 我必须跟总经理室说: “让我们稍微改进一下吧!”
这里,我也并不认为,现在软件中心已经达到流程精简的阶段了(这还不现实,我的在我的工资也还没到10000),
我们是讲:这只是我们将来的趋势.而目前,我们对文档流程的要求是:要尽量有用!与我们的工作实际结合.
下面,我们希望广泛参考IDEF0，IDEF1X，RUP，甚至对于敏捷开发的思想，微软一些成功的做法，然后探讨一些能很好结合软件中心实际的一套软件开发流程！
本文仅起抛砖引玉的作用,希望大家广泛讨论,并最终对目前需求部,总体部的流程制订起一些参考作用!
曾经接触过一个项目组:
他们在一个多月里,需求分析与概要设计阶段,抽调了包括项目经理和刚进公司几天新人的所有组员,全部精力做一件事情-----用VISIO赶画DFD图,.
开始用DFD来写文档,-----------这是中心的一大进步,但是我不知道:
他们有多少人知道,DFD应该如何正确地画;
为何要画这些图,它们最终目的是什么(难道仅仅因为现在总中心的流程要求吗?)
这些图最终起了什么作用?
是否有人对这些图进一步使用,进一步交流,进一步分析,提炼?
这些问题不得而知.但是最后他们以提交了数百页得概要设计书为里程碑--------结果似乎是皆大欢喜的.
总中心和产品部都很满意;
杂音微弱:项目经理或成本控制部门: “一方面要求我们下月整个项目,一方面且要求我们提交这么多过渡产品”
而整个项目的最终结果----------工期延期了.不过,问题不大------- “你们项目组每一步都已经很严格按照流程标准来走了,所有组员也都在加班.作为项目经理你是没有责任的,责任只在于我们低估了工期和成本!”
我们的产品成本真的偏低吗?----------不,我们在与外面企业竞标事,成本报价从来不占优势.
因此,现在的问题是:
花费了这么多 “人月”的中间工作产品,到底谁在乎?(可悲的是:连项目组内也没有多少人将数百页的文档全部阅读完)
这些中间工作产品起了什么作用,是否确实对系统的质量\架构起了作用.
需求分析，概要设计书必须有用，务实！，不要过分追求语言润色、排版美观。我们的文档不是为了给老师评分，给工委会好评，不是为了在报刊发表！ ----我们所有的行为应该 是企业行为，必须考虑有效性，必须考虑效益，成本。
“我不愿意再去写一些，很少人看，并且进了产品控制部，就再也没人去查看的文档！”
但是,在需求分析，概要设计阶段中,什么工作才是有用的,什么中间产物是需要保存的---------- 这是我们讨论的重点!
需求分析，概要设计书的要素：（这些规格书，需要包括哪些必要产物？）
决定要素的因素：
写这些规格书的目的，它是为了下一阶段的哪些目的而写的？本阶段的产物对下一阶段的工作有帮助？
谁将来要看这些规格书？（谁会需要该阶段的产品？）
想法二：（交流）
作者在写各个阶段产品的文档时,必须很明确读者对象是谁,然后,只表述该对象能理解的内容;
核心工作流程简介
核心工作流程显示生成特定的工件集可能要经历的所有活动。我们概括地描述了一下这些工作流程 - 涵盖了所有涉及的角色、活动和工件。同时还更详细地展示角色如何协作、使用并生成工件。对这些步骤的详细说明称为“工作流程明细”。
每个核心工作流程说明如下：
简介
该工作流程的目的以及和其他工作流程的关系。
概念
对理解核心工作流程十分重要的核心概念。
工作流程明细
实施工作流程典型的事件顺序，以工作流程明细表示。工作流程明细是一组“同时”完成的活动，与输入和结果工件一起介绍。
活动概述
工作流程中的活动和角色。
工件概述
工作流程中生成的工件和负责的角色。
指南概述
有关如何使用和生成流程的工件的详细解释。
需求调研与整理
简述
概念
流程明细---需求调研与整理
需求分析
1. 事物与事件列表
2. 确定实体
3. 用例与参与者Use Case 图\系统边界图\\类图(系统关联图(则0级DFD)+ERD)
4. 场景图(DFD)
5. Seq图\状态图\协作图(DFD)
6. 设计类图(数据元素定义)
7. 包图\ (结构图)
8. 类行为定义(过程定义IPO\伪码描述)
9. 关系数据库
10. 用户界面\对话框\表格\报表
使用bpwin做业务核心和数据流图的建模（idef0 + idef3 + dfd）；或者使用业务调查，直接用PowerDesigner 6 ProcessAnalyst做数据流图的建模(dfd)；用visio做相关的硬件、网络系统、部署等的设计建模；
可以把数据流图转变成uml的usecase和sequence；
概要设计阶段：
使用PowerDesigner(或者erwin，推荐pd)做数据库结构逻辑设计；
用visio做系统结构图；
用PowerDesigner做类图设计；或者使用rose 2001继续以下的过程；
详细设计阶段：
重要的流程可以使用visio做流程图
整个过程建议项目经理采用Project控制跟踪
erwin支持idef1x即信息建模，就是我们常说的er图、实体关系图，也就是数据库结构图。
bpwin支持idef0/idef3/dfd，是功能与流程建模，主要用来描述企业的业务流程，比uml的usecase/sequence更适合描述复杂逻辑 |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有帐号？立即注册
x
|
发表于 2022-9-11 10:53:04
