软件过程管理软件过程框架实践教学教案.docx

软件过程框架实践目录1前言41.1背景41.2从实践中来到实践中去41.3开发辅助工具选型策略41.4迭代开发模式策略41.5快速发布与迭代策略51.6快速开发框架策略51.7文档编写策略62需求分析72.1不可缺失的内容72.2工具72.3产出72.4规范72.5迭代83软件项目计划83.1资源估算83.2工具83.3计划制定93.4任务分解方法93.5计划跟踪与调整103.6规范104面向对象设计104.1工具114.2产出114.3规范115面向对象编程115.1工具115.2产出115.3规范116面向对象测试126.1产出126.2步骤策略127缺陷跟踪、维护阶段127.1工具127.2规范128配置管理128.1工具138.2规范139质量跟踪139.1需求分析质量跟踪139.2项目计划质量跟踪139.3面向对象设计、编码质量跟踪139.3.1测试任务149.3.2规范执行度检查149.3.3面向对象复用度检查141前言1.1背景软件工程已经有了40多年的发展历史，但是它仍然没有成为一种成熟的学科。敏捷、CMMI、RUP，各种软件开发方法层出不穷，潮来潮去，让一线开发人员无所适从。产业界实践与学术界研究分歧严重。。。也许这本身就不应该成为一门学科。近年来，软件的理论界和实践者在软件开发过程的定义、度量、改进方面做了大量的研究，提出了大量的过程模型、度量方法、度量标准、改进策略，但现有的大部分方法过于宏观、抽象、复杂，作为战斗在第一线的实践工作人员，如何做到理论联系实际，执行一套行之有效的简单、实用、科学的过程模型，直接帮助开发者定义、评价、改进过程, 提高开发者的软件研发能力，这些是本文所探讨的问题。1.2从实践中来到实践中去本文力求从实践中来到实践中去，自觉抵制三话（假话、大话、空话）之类的行为与思考模式。在这里，软件工程管理上的灵感都应该来自于第一线的实践工作，欢迎读者提供更多的实践经验来丰富本文内容，共同打造出一套行之有效的软件过程框架。1.3开发辅助工具选型策略本文对于开发辅助工具的选型上，以适用、实用为前提。我们在软件过程当中应该关注如何做到有效的管理，而不应该迷信工具，如“夸父追日”般年复一年地追索，认为工具能解决现实中所有的问题，似乎用了什么什么就能提高管理水平，这是不切实际的奢望，因为管理水平将最终从具体个体的水平体现出来，就比如不会玩游戏的人给他再好的装备都死得一样快。其实很多实用的工具就在身边，问题是如何选择、利用它们来武装自己，简单、实用、能解决具体问题就行。任何工具都仅仅是作为管理的一种辅助手段，必须有机的结合起来，才能达到目的。1.4迭代开发模式策略迭代开发是OOA/D成为最佳实践的核心，敏捷实践是有效地应用UML关键。相对于“瀑布”生命周期，迭代和进化式开发对部分系统及早地引入了编程和测试，并重复这一循环。这种方法通常会在还没有详细定义所有需求的情况下假设开发开始，同时使用反馈来明确和改进演化中的规则说明。在迭代开发中，我们依赖于短时快速的开发步骤、信息反馈及针对反馈信息的改写来不断明确需求和设计。相比之下，瀑布模型提倡在编程之前就预先完成需求和设计步骤，而这往往在现实项目当中是不切实际的奢求。研究表明，瀑布模型与软件项目高失败率具有极大的关系，而迭代方法与较高的成功率、生产率和低缺陷率具有关系。迭代开发是以小步快进的方式，根据用户和测试反馈信息（测试驱动）不断层叠推进，才能得以保障在有限的开发周期内完成项目。对于用户和测试反馈不及时、对于反馈不及时处理或者无故吃掉等行为，都是项目管理的大忌，必须避免。1.5快速发布与迭代策略需求在开发过程当中发生改变是不可避免的，用户通常在工程开始的时候并不能确定他们想要的是什么。当我们采取快速发布策略时，可将工程变动提至较早的时间段，这是保证迭代开发成功的基础，否则就和瀑布模型没啥两样。瀑布模型最大的恐怖在于需求变更在上线前大爆发，这一般是因为直到上线前一刻，用户才体验到你的系统到底和他所想象的有多大区别，而在此之前用户和开发者基本处于两个语境当中。对于每个项目来说，我们将以往项目现成的主程序和主界面作为基线，复用他们，即刻部署一个框架性的应用系统，发布的初版可能仅仅是登陆界面、带系统管理模块（用户、权限、角色、片区管理等已组件化的通用模块）的主界面。在项目开发过程当中，一旦需要新增模块，就可以在主界面上添加相对应的菜单并做权限配置等：具体方法见《常规_窗体类_MainForm.pdf》。如此，在开发过程当中，可即刻部署到内部测试环境或者用户体验环境中，使得用户可以及时发现问题及时提出问题及时迭代。形成一个良性的信息反馈链。最终，当正式提交用户的时候，将会是个无缝过渡的上线过程，或者至少不至于出现颠覆性的需求变更。1.6快速开发框架策略RAD技术需要