1. 软件过程
最早的软件开发，并没有很明显的过程模型，一切工作都是顺其自然的。随着人们经验的积累以及项目规模扩大的需要，人们不断地总结出各种软件过程模型，用来指导人们软件开发的过程。过程模型包括软件开发过程的规定以及相应的角色定义、制品定义。比较常见的有瀑布模型和增量模型。很多过程模型都是由这两者演化而来的。现在增量模型中的迭代的思想近乎为所有的流行过程模型所采用。这里要重点说一下瀑布模型。现在普遍认为瀑布模型已经过时，是不应采用的。其实，我觉得实际项目中，瀑布模型是非常有效的，需要去掌握。瀑布模型的优势在于符合软件开发的思维过程并且容易掌握和运用。过程模型的运用是以深刻理解为前提的，一知半解地套用模型反而会给项目带来灾难性后果。在实际的项目中，应该是借鉴某（几）个模型，结合自己团队的实际情况制定自己团队的模型。过去的项目经验看来，瀑布模型是相当不错的，但是不能单纯的使用。应该先运用增量迭代思想将项目分割成可以逐步增量的小系统（一次发布）。每次发布为一个迭代，每次迭代系统的规模和复杂度小到足以用瀑布模型来开发。
当前业界最有影响力的应当是统一过程模型（UP），在UP模型中，以Rational公司提出的RUP模型最有影响力，并有完善的工具支持。RUP以用例为中心，使用UML的9种图形作为交流语言。RUP在项目之初就制定详尽的用例说明，并指定了很详细的计划。RUP关注文档制品，大部分的活动都产生丰富而完备的文档。RUP将系统开发分为若干次迭代，每次迭代都都包括需求、分析、设计、实现、测试等工作流。每个工作流都规定了输入制品、输出制品、参与角色、工作流的具体活动内容。RUP被称为重型软件过程模型，它包含几十个角色，上千份文档制品并和Rational的系列工具紧密结合。因此，我们在实施RUP的时候，一般都要进行删减，有选择地实施。
由于统一过程在很多时候过于烦琐，实施成本太高，并且对需求的变化反映不够敏捷，因此，敏捷过程越来越受欢迎。敏捷过程是一系列轻量的过程模型的总称，其代表是XP（极限编程）模型。敏捷过程的主要思想可以从《敏捷软件开发宣言》看出：
我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为：
l 个体和交互 胜过 过程和工具
l 可以工作的软件 胜过 面面惧到的文档
l 客户合作 胜过 合同谈判
l 响应变化 胜过 遵循变化
虽然右项也有价值，但我们认为左项具有更大的价值。
在此，以最完善也最有代表性的XP来说明敏捷开发的一些做法和原则：
1. 客户作为团队成员。这样可以保证获取有效的需求。客户要能和团队一起工作。该客户必须了解该项目需求，并对项目的需求变化具有发言权。如果客户方无法一起工作，则需要找一个代替者，其需要能完整理解并表达客户的需求，比如可以是可以对客户需求负责的领域专家，可以是需求调研归来的业务分析员。
2. 使用用户素材作为记录需求的材料。用户素材记录和用户交谈的信息要点。XP不鼓励过早分析用户素材并形成格式化的需求规格说明书，因为这些工作会在需求发生变化后变成无用功
3. 短期交付。XP通过不断提交可运行的产品来增强客户的。XP每两周交付一个工作的软件版本。每次迭代中根据优先级别和依赖顺序来选择实现一一些用户素材。XP还通过发布计划来规划一个更长的周期内要实现的用户素材。
4. 结队编程。这是XP中创新的开发模式，两个共用一部机器从事编程工作。同时，每个对子是自由组合和经常变动的。这样可以促进团队成员的互相学习，并保障编码的质量。事实证明，结对编程不会降低效率。
5. 测试驱动开发。编写类时，先写这个类的测试类。这种“带着想法编程”的模式，目标非常明确，测试类调试通过的时候，目标类就编写完成并经过测试了，并且测试类还是很好的文档，它描述了类该如何使用。
6. 一起工作。项目的成员一起在一个开放的空间工作。这是保持良好沟通的保证。
7. 保持最简单的设计。能简单的事情不要复杂化。避免重复的代码，所有的代码如果出现过两次，你应该马上想到如何抽象以消除重复的代码。
8. 代码就是设计。XP认为代码就是最好的设计文档，代码比其他文档更容易说明问题。尤其是测试驱动开发模式下，测试代码就是最有价值的设计文档。其他的UML图表仅起辅助说明作用。
经过一段时间的实践证明，在像WebOA.NET这样的中小型项目中敏捷过程比统一过程更容易实施也更加有效。
1.3. KIND WEBOA.NET项目的软件过程
每一个软件过程模型都要考虑到：方法论、文档规范、角色分工，我的做法是在项目计划中就定义了以上内容，同时编写一个软件过程说明书做详细说明。
1.3.1. 过程方法
本项目之初，制定项目计划的时候，是以统一过程为参考的，到项目过半的时候才加入敏捷过程的一些做法。同时，CMMI为确保软件的质量，提出了若干标准及建议做法，我在确定项目开发过程中的部分做法时，参考了部分这方面的内容，比如风险管理和项目汇报机制。项目的过程示意图如下：
整个项目参考UP分为准备阶段、定义阶段、设计阶段、实现阶段、产品化阶段，将任务归为若干工作流。所有工作流分成三个集合，三条线并行。项目管理集的任务是计划和监督类工作，多为周期性任务。研发集的任务则是随着项目的进行细化的。支撑级则包含了为了确保上面两类工作顺利完成的任务。下面重点说明本项目的研发过程。
首先是需求分析，因为是产品化的项目，需求并不来自特定的客户，所以就少了需求调研，需求调研阶段安排做需求收集。需求收集完之后进行分析，将需求整理成《需求描述》和《用例规格说明书》。需求分析的过程中，会不断地对需要的技术有个大致的估计，安排技术人员对一些关键技术做预研，这个是降低风险的有效做法，也为以后的时间表的建立提供依据。需求分析完成后，进行一次评审，然后将需求分为若干子系统，进入每个子系统的迭代开发。每一次迭代中，有以下几个工作流：UI设计、架构设计、数据库设计、业务分析（类设计）、单元测试、集成测试、实现，每个工作流结束的时候都产出与一份文档并接受评审。我们采用的是UI先行的原则，UI直接对应需求，其余的工作都是为了让UI的功能实现。这样带有明确的目的性，实际上是一种模块级别的“测试驱动开发”，实践证明，是很好的方法。项目过半后，因为引入XP，所以缩短了每次迭代的周期，这让每次迭代的过程中，各工作流的时间长度都缩短到两三天，所以不再强调输出文档，而是直接对可运行的发布版本做评审。实践证明，这更有效而且节约时间，老板可以不断看到系统的进展。此外，还将单元测试和实现结合起来不做区分。
角色定义
根据本项目的人力资源特点，定义了以下的角色。
| 角色 | 工作说明 |
| 项目经理 | 项目管理、进度控制、软件过程指导、质量评审、制定规范 |
| 系统分析员 | 统筹安排需求分析、架构设计、模块设计 |
| UI设计 | 表现层的设计 |
| 数据库设计 | 数据层的设计 |
| 配置管理员 | 配置管理的各项工作 |
| 开发人员 | 负责模块的详细设计和实现以及单元测试 |
| 文档管理员 | 组织编写文档，管理文档 |
| 测试经理 | 统筹安排测试活动 |
需要说明的是，角色和人员还是有很大区别的，实践经验告诉我们，角色要定义清楚，什么角色的人承担什么责任要明晰，而人员可以根据情况，身兼多角色。这个时候，一个成员扮演一种角色时，就做该角色要做的事。
1.3.2. 文档规范
本项目在整个过程中产生如下文档，大部分文档也都是迭代完成的。需要说明一点的是，文档需要标准，这个标准包括需要哪些文档，由谁完成，包含那些内容，用什么样的格式等，但是文档不一定要严格参照诸如国标之类的标准。自己制定适合自己的标准是最好的做法。
l 项目开发计划。每周计划审查后推出一个新的版本。
l 项目计划变更报告。和新的项目计划配合，对计划的变动说明原因
l 需求规格说明书。分点描述产品的功能，是结项验收的依据。
l 用例规格说明书。仔细描述系统行为，是最主要的需求材料和开发的基础
l 每日任务书。分配到每个人。（对于大的团队，可以分配到小组长）
l 项目总结报告。分为周报、月报。统计工作量和工作成果并进行评价
l 架构说明书。说明架构方式，目录组织，命名规定以及采用的平台技术，作为详细设计和实现的依据
l 结项报告。项目结束后的总结
l 模型：数据库ER图，系统的类结构图，体现系统的设计。完成时导出，让后人参考。
l 代码：代码就是设计，因此没有详细设计文档。结合类结构图，阅读代码、注释及其测试代码，就可以弄清系统的设计。
l 集成测试反馈报告。包括测试用例描述和BUG描述
l 需求变更报告。描述需求的变更提起人，变更原因，审批结果。保持一份通过审批的需求变更列表。
1.3.3. 工具与平台
本次项目采用微软的 WINDOWS2000+.NET Framework1.1+SQL SERVER2000 为平台，使用 MS PROJECT 2000 作为项目计划工具，使用 CVS 作为配置管理工具使用 VISOR 作为 UML 绘图工具，使用 VS.NET 2002 作为开发实现工具。
扫一扫
549
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
