（计算机软件与理论专业论文）中小型软件开发过程的管理与控制.pdf

摘要 摘要 软件开发过程的控制和管理一直是软件工程与项目管理领域的研究重点 在 各种计算机应用软件开发过程中起着举足轻重的作用 但是目前的各种理论和 方法的研究或者过于抽象 可操作性差 或者过于局限 不能覆盖完整的软件 开发流程 本文针对中小型应用软件开发 依据角色分工对项目管理规范和技术研发方 法进行了研究 建立了一套完整的 可操作的软件开发管理与控制体系 包含 需求分析 配置管理 进度控制 文档代码规范 测试管理 b u g 管理 发布管 理等重要方面 覆盖了软件开发的完整过程 本文创造性的提出了 需求纵向划分 设计横向汇总 的方法 将软件开发 的需求分析与设计工作进行了有机的整合 由此建立了完整的项目文档管理体 系和开发控制管理体系 本文一并提供了完整的项目文档模板集合 能够满足 实际开发过程的需要 本文研究成果在多个欧美软件工程项目和国内应用软件开发项目中得到了 成功应用 文中大量的真实项目案例信息论证了各种管理规范的可操作性和有 效性 因此 本文的研究工作对提高国内中小型软件开发的项目管理水平有着 重要的推动作用 关键字 软件过程 管理规范 软件团队 a b s t r a c t a b s t r a c t t h em a n a g e m e n to fs o f t w a r ed e v e l o p m e n tp r o c e s sh a sa l w a y sb e e na ni m p o r t a n t s u b j e c ti n t h es o f t w a r ee n g i n e e r i n ga n dp r o j e c tm a n a g e m e n tf i e l d s i th o l d st h e b a l a l i c ei na 1 1k i n d so fs o f t w a r ed e v e l o p m e n tp r o c e s s e s h o w e v e r m o s to ft h ec u r t e u t t h e o r i e sa n dm e t h o d sa l et o oa b s t r a c tt op u ti n t op r a c t i c eo rt o on a r r o wt oc o v e rt h e w h o l es o f t w a r ed e v e l o p m e n tf l o w i nt e r m so ft h ew o r ka s s i g n m e n ti nap r o j e c t al o to fs t u d ya n dr e s e a r c hw o r kh a s b e e nd o n ef o rs m a l la n dm e d i u m s c a l e ds o f t w a r ep r o c e s sm a n a g e m e n ti nt h i sp a p e r a n das e to fe x e r c i s a b l es o f t w a r e p r o c e s sm a n a g e m e n tr u l e s a r ee s t a b l i s h e d i n c l u d i n gr e q u i r e m e n t sa n a l y s i s c o n f i g u r a t i o nm a n a g e m e n t s c h e d u l e c o n t r o l d o c u m e n t sm a n a g e m e n t c o d i n gs t y l e c o m m u n i c a t i o nr u l e s t e s tr u l e s b u gt r a c k i n g a n dr e l e a s en o t e s e t c t h er e s u l t sa r er o u n d e da n dc o v e rt h ew h o l ed e v e l o p m e n tf l o w a n e w a n a l y z i n gr e q u i r e m e n t sv e r t i c a l l y m a k i n gd e s i g nh o r i z o n t a l l y m o d e li s p r e s e n t e di nt h i sp a p e r i tc o m b i n e st h er e q u i r e m e n ta n a l y s i sw i t ht h ed e s i g nw o r k a n dt h e r e b ys e tu pap r o j e c td o c u m e n tm a n a g e m e n ts y s t e ma n dd e v e l o p m e n tc o n t r o l m a n a g e m e n ts y s t e m m o r e o v e r as e r i e so fd o c u m e n tt e m p l a t e s a l eo f f e r e dt om e e t t h ep r a c t i c a ld e m a n d s t h er e s u l to ft h i sp a p e rh a sb e e na p p l i e ds u c c e s s f u l l yi nm a n yo v e r s e a sa n d d o m e s t i cs o f t w a r ep r o j e c t s al o to fa c t u a lp r o j e c tc a s e si nt h ep a p e rp r o v et h e m a n e u v e r a b i l i t ya n dv a l i d i t yo ft h eo f f e r e dr u l e s t h e r e f o r e t h es t u d yo ft h i sp a p e r w i l lh e l pi m p r o v ea n dr a i s et h el e v e lo fd o m e s t i cs o f t w a r ep r o j e c tm a n a g e m e n t k e y w o r d s o f t w a r ep r o c e s s m a n a g e m e n tr u l e s s o f t w a r et e a m i i 内容目录 图目录 图1 1 软件开发过程的基本流程 3 图1 2 软件过程成熟度的五个等级 4 图3 1 软件团队的人员分工 1 0 图3 2 需求到设计的跃升 1 1 图3 3 文件夹结构示例 1 6 图3 4 文档修订记录示例 1 7 图3 5 版本号组成 1 7 图3 6 甘特图 2 0 图3 7p e r t 图 2 1 图3 8 改进后的p e r t 图 2 1 图4 1 文档图文示例 一d l r e a d e r 系统s c r 模块结构图 2 5 图4 2 南开越洋软件公司最小文档集 2 7 图4 3d l r e a d e r 文档示例 2 8 图5 1 开发流程与测试流程 图5 2 软件测试的信息流 3 6 v i 内容目录 图5 3 软件测试的工作流程 3 6 图5 4b u g 管理的工作流程 3 8 图5 5b u g 生命周期 4 0 v i i 内容目录 表目录 表3 1 用户登录控制规则 1 1 表3 2 用户数据表 1 1 表3 3 审核文档表格示例 1 8 表3 4 工作量划分 2 0 表4 1 文档分类 2 3 表5 1 b u g 的描述方法 表5 2b u g 的优先级 3 9 表5 3b u g 的严重程度 3 9 表5 4b u g 分布示例 4 0 表5 5 表格识别系统的b u g 记录 4 2 v i n 南开大学学位论文版权使用授权书 本人完全了解南开大学关于收集 保存 使用学位论文的规定 同意如下各项内容 按照学校要求提交学位论文的e p 届 j 本和电子版 本 学校有权保存学位论文的印刷本和电子版 并采用影印 缩印 扫描 数字化或其它手段保存论文 学校有权提供目录检索以及提供 本学位论文全文或者部分的阅览服务 学校有权按有关规定向国家有 关部门或者机构送交论文的复印件和电子版 在不以赢利为目的的前 提下 学校可以适当复制论文的部分或全部内容用于学术活动 学位论文作者签名 每拖 河年6 刷日 经指导教师同意 本学位论文属于保密 在年解密后适用 本授权书 指导教师签名 学位论文作者签名 解密时间 年月日 各密级的最长保密年限及书写格式规定如下 f 礴鬻雾l 藜藏i 蘸鬻灞黍嚣蠢萋一 曩 l l 穗湖凝隐舔羹激删麟羹纛一t 辩l 蹙鬻爹爹一ii l 夔鬻鹱i 燮燮攀懿蘩攀藜 黉囊l 南开大学学位论文原创性声明 本人郑重声明 所呈交的学位论文 是本人在导师指导下 进行 研究工作所取得的成果 除文中已经注明引用的内容外 本学位论文 的研究成果不包含任何他人创作的 已公开发表或者没有公开发表的 作品的内容 对本论文所涉及的研究工作做出贡献的其他个人和集 体 均已在文中以明确方式标明 本学位论文原创性声明的法律责任 由本人承担 学位论文作者签名 互多色 a 西年6 月 e l 导论 第一章导论 第一节软件项目管理的背景和概念 1 1 1 项目的概念和项目管理的背景介绍 项目 的概念 有很多 本文提到的项目概念定义如下 项目 一个有目的 有计划 有始有终 按照预定步骤和进程 为完成特 定任务而进行的工作和活动 最早的项目实践可以追溯到几千年前的埃及金字塔建设 到十九世纪早期 工业革命爆发 现代化的工业管理开始萌芽 二战爆发后 武器设备等各种项 目复杂度激增 项目管理 的概念提上日程 而直n 十世纪中期 项目规模 日益庞大 美国著名的曼哈顿工程终于拉开了现代项目管理的神秘面纱 二十 世纪末至今 科学技术飞速发展 项目管理的概念和技术更是渗入到我们生活 的各个领域 甘特图 关键路径 c p m 计划评审 p e r t 以及网络技术的 应用 使得诸多复杂的项目得以顺利进行 现代项目管理的知识体系逐渐成型 1 9 6 9 年 美国成立了项目管理学会p m i p r o j e c tm a n a g e m e n ti n s t i t u t e 致 力于项目管理知识的研究 大大推动了项目管理的发展 该组织推出的项目管 理知识体系p m b o k p r o j e c t m a n a g e m e n t b o d yo f k n o w l e d g e 把项目管理归纳 为范围管理 s c o p em a n a g e m e n t 时间管理 t i m em a n a g e m e n t 成本管理 c o s t m a n a g e m e n t 质量管理 q u a l i t ym a n a g e m e n t 人力资源管理 h r m a n a g e m e n t 信息交流管理 c o m m u n i c a t i o nm a n a g e m e n t 风险管理 r i s k m a n a g e m e n t 采购管理 p r o c u r e m e n tm a n a g e m e n t 和综合管理 p r o j e c t i n t e g r a t i o nm a n a g e m e n t 九大知识领域 2 现在 这种项目管理方法已经得到全 球范围的普及和认可 项目管理学科日臻完善 1 1 2 软件开发的历史与独特性 随着信息产业的兴起和不断前进 越来越多的项目必须借助计算机的帮助才 能得以完成 相应的软件行业日益繁荣 和其他领域相同 软件行业同样需要 第1 页 导论 借助项目管理的知识才能蓬勃发展 早期的软件开发规模小 不需要分工合作 其成功完全依赖于个人能力 随 着行业和技术分工的日益明细 软件规模越来越大 个人的 骑士精神 和小 规模的合作已经不能满足需要 到了6 0 年代中期 著名的 软件危机 爆发了 北约会议提出了软件工程的概念 初期的软件项目管理理念开始形成埽j 目前 对软件的通用理解为川 软件一计算机系统中与硬件相互依存的另一部分 它是包括程序 数据及 其相关文档的完整集合 程序一按事先设计的功能和性能要求执行的指令序列 数据 使程序能正常操纵信息的数据结构 文档 与程序开发 维护和使用有关的图文材料 软件开发具有与众不同的特点 它既要求巧妙的算法 奇特的构思 更需要 缜密的设计和严格的工程化环境 正是这种创造性和严谨性 艺术性和科学性 的融合 使得软件开发显得复杂而神秘 软件项目的管理则充满了挑战和技巧 1 1 3 软件过程的概念与现代软件项目管理 在技术与市场迅猛发展的今天 软件业不可避免的受到冲击和影响 软件复 杂度的大大增长 大型系统对不同领域知识的要求 纷繁复杂的商业模式对开 发流程的要求 所有这些影响不得不使软件开发面临管理方式的重要变革 由此带来的项目管理 团队协作 软件复用等等问题是我们必须面对和解决的 近年来 人们对于软件工程的研究越来越多 由此应运而生了软件过程的概 念 软件工程需要研究 如何做 的软件方法 也要研究支撑的软件工具和软 件环境 软件过程则是研究如何综合软件方法和软件工具 5 美国c a r n e g i e m e l l o n 大学的软件工程研究院 s e d 在软件能力成熟度模型 c m m 中给出 定义 过程 人们用以开发和维护软件及其相关产品 例如 项目计划 设计文 档 代码 测试用例 用户手册等等 的一组活动 方法 实践和变换 6 第2 页 导论 第二节软件过程管理方法的发展综述 1 2 1 软件过程管理的主要内容 一个软件的开发流程主要包括五个阶段 启动阶段 客户需求分析 项目启动 计划阶段 确定系统范围 进行概要设计和详细设计 实施阶段 技术实现 功能性能评测 结束阶段 代码封装 系统发布及技术支持等 控制阶段 贯穿整个开发流程 保证项目以完善的功能性能按时提交 紧糕躐i 黉襞酉己謦0 被术支掰 图1 1 软件开发过程的基本流程 前面提到 软件过程管理是研究如何综合软件方法和软件工具 那么自然要 包括在软件开发流程中所遇到的包含文档管理 代码规范 测试管理 配置管 理 发布管理及信息交流 进度控制等一切保证项目顺利进行的管理性问题 我们必须摒弃 软件就是编程 这种原始的简单概念 在当今复杂的软件开 发过程中 除了高质量的编码 建立并维护良好的软件开发工程环境 完备灵 活的文档管理体系以及各项严格的规范制度都占有举足轻重的地位 这些都是 在现今环境下保证高质量软件开发所必备的 1 2 2 软件能力成熟度模型 c m m 简介 人们关于通过应用新的软件方法和技术能提高生产率和质量的希望 经过 了2 0 年仍未实现 于是工业和政府组织意识到 他们的基本问题是不能管理其 软件过程 6 1 9 8 6 年1 1 月 s e i 开始研制能帮助组织改善其软件过程的成熟 第3 页 导论 度框架 并于1 9 9 1 年发布了软件能力成熟度模型 c a p a b i l i t y o f m a t u f i t y m o d e l c m m 的1 0 版本 软件过程成熟度是指一个特定的过程被明确的定义 管理 测量 控制 并 且是有效的程度 成熟度意味着能力上的增长潜力 并且标明一个组织软件过 程的丰富性和在遍及组织的项目中运用它时的一致性 软件过程成熟度意味着 由于运用组织的软件过程使过程纪律性一直增强 从而其软件过程所导致的生 产率和质量能随时间的推移得到改进 过程的不断改进基于许多小的 进化的步骤 而不是革命性的创新 c m m 提供了一个框架 将这些进化步骤组织成五个成熟度等级 它为过程不断改进 奠定了顺序渐近的基础 并定义了一个有序的尺度 用以测量组织软件过程成 熟度和评价其软件过程能力 还能帮助组织对其改进工作排出优先次序 图1 2 软件过程成熟度的五个等级 1 2 3 软件过程管理现状 对于软件过程研究的逐步深入带来了全世界范围内软件企业能力的提升 s e i 的c m m 标准是在软件过程研究领域不可否认的权威 然而 抛开其存在的 种种缺陷外 是不是所有的企业都适用这么庞大完善的管理体系呢 目前 国 内的软件企业项目管理水平参差不齐 多数还处于一种混乱的管理状态 与世 界先进水平相去甚远 而现在很多企业却似乎陷入了认证的陷阱 诸多的标准 规范 使得企业盲目的急功近利 据2 0 0 3 年一份调查统计 全世界共有超过2 0 万家软件企业 而选择c m m 评估的仅有2 3 0 0 家 仅占l 第4 页 导论 极限编程 e x t r e m ep r o g r a m m i n g x p 是近年来提出的一种新的软件理念 这种轻量级开发方法主张重新审视开发环节 去除臃肿累赘 严格控制除程序 量以外的 文档量 x p 给开发带来便捷的同时 也应看到它的局限性 在 开发中缺乏一定的预见性 容易造成结构性的质量问题 必须花大力气补救 7 1 第三节中小型软件开发的管理 1 3 1 中小型软件开发的特点 软件开发的复杂性决定了不能对所有类型的项目给出通用的管理规范 本文 针对的目标主要是项目规模较小的软件开发过程 本文界定的具体范围为团队 成员在二十人之内 软件项目周期在十人年之内的软件开发项目 这类软件项 目在我们e t 常生活中接触最多 应用也最广泛 因此对这类项目的过程管理研 究是很多人关注的焦点 具有普及意义 对软件过程管理现有的一些理论和规范阎 9 基本上是基于环境和功能都比 较完备的大型开发 给出的管理模型和方法也是比较适用于需求严格 模块繁 多的大型软件项目 拿权威的c m m 标准来说 它定义了条目繁多的关键过程域 一个中小型的软件开发过程根本没有必要按照这么严格的标准来实施 对比大型软件开发过程 中小型软件的开发具有自己的特点 1 0 1 1 具有一定的技术难度 成本不高 但时间要求却相对紧迫 2 需求变更频繁 难以建立完整的过程管理流程 3 开发团队的技术水平比较高 但管理水平相对薄弱 4 软件开发的过程不完整 重技术而轻服务 可以看出 庞大的c m m 标准虽然已经非常成熟 但是其主要针对的目标是 相对大型软件项目的过程管理 它实际上是对企业软件能力的评估模型 对于 中小型的软件开发 c m m 具有以下不适用性 1 复杂性高 实现难度大 2 概念性强 可操作性差 3 注重共性 缺乏灵活性和针对性 第5 页 导论 1 3 2 项目管理的重点和难点 针对上面提到的诸多特点 中小型软件开发过程的管理难点和重点就在于 1 如果进行团队成员的工作划分 按照技能长项合理分工 2 如何规划开发过程 建立内部的过程管理规范 3 如何保证开发进度如期完成 软件质量符合要求 4 如何满足频繁变更的客户要求 树立良好的形象 为了解决上述问题 我们需要建立起适合中小型软件开发的完整制度规范与 团队成员的行为规范 保证软件项目的顺利实施 本文给出的规范将建立在角 色分工明确 知识技能划分清晰的基础之上 将开发过程中的管理经验 方法 抽象并提升成普遍适用的标准和规范 具备很强的可操作性和重复性 1 3 3 管理规范的分类与内容组成 软件过程管理规范必须要贯彻软件的启动 计划 实施 结束和控制整个开 发流程 将这些规范纵向分解 可以抽象为下列内容 1 文档规范 结构完整 描述清晰的文档 可以保证项目的顺利进行 弗且传 承企业文化 积累项目经验 软件开发中的文档规范包含文档类型 编写人 员 阅读权限 版本变更等内容 2 代码规范 包含软件流程与结构的定义 算法与接口的设计 以及代码的书 写规范 版本控制等内容 3 配置管理规范 配置管理是协调软件开发过程 使得各种混乱和错误减到最 小的技术 内容主要包括对客户信息和数据 内部软件工程环境等内容的管 理 配置管理是管理工作的核心内容 4 测试管理规范 主要围绕测试工作的组织管理 测试环境的建设维护等 这 些都是保证项目质量的关键因素 在软件开发过程中的地位非常重要 5 b u g 管理规范 没有b u g 的完美系统是不存在的 b u g 管理主要阐述软件 b u g 的定义 b u g 库的建立 解决b u g 的流程及b u g 管理的环境配置等内容 6 进度控制管理规范 主要讨论控制软件进度按时完成应遵循的原则和采用的 方法 如里程碑定义 工作量划分 甘特图等 7 通信交流规范 针对软件开发团队内部和外部交流形式 内容及时间等进行 管理的规范 可以增进团队成员之间的感情 避免权责不清等问题的出现 第6 页 导论 第四节本文研究目标与内容组织 真正的改造软件开发过程 制造出优质的软件是我们追求的最终目标 本文 正是基于这样的目的 针对目前国内多数的中小型软件开发的特点及管理重点 和难点 制定出一套切实可行的过程管理规范 来保证软件项目的顺利进行 本文将针对软件开发过程中的各项内容分别制定出相对具体的操作规范 使得 软件开发有章可循 有理可依 本文摒弃了以往按照生命周期顺序研究软件过程的纵向角度 以一种全新的 角色分工角度进行阐述 对项目经理和团队开发人员在工作中的侧重点进行分 析指导 并从配置管理 进度控制 文档管理 代码规范 通信交流管理 软 件质量保证等横向角度进行分析总结 辅以大量的工程实例 制定了一整套相 对具体 可重用的软件过程管理方法 本文观点提炼自南开大学机器智能研究所和南开越洋软件公司多年来软件 开发的技术和管理经验 经过多个软件项目实践证明 具有可行性和可信性 本文内容共分为五章 第一章 导论 介绍软件项目管理的背景和中小型软件开发的特点 第二章 需求分析的确定与过程综合管理 从项目经理角度 讨论软件开发 过程中的需求制定 配置管理和进度控制等规范 第三章 软件过程管理规范与技能经验总结 从团队成员角度 讨论软件开 发过程中的文档管理 代码规范 通信交流管理等内容 第四章 软件质量的管理与控制 针对软件价值的实现 讨论测试管理 b u g 管理以及软件发布等内容 第五章 实践案例与结论 第7 页 需求分析的确定与过程综合管理 第二章需求分析的确定与过程综合管理 中小规模的软件团队通常人才能力水平相差较大 通常 项目经理和经验丰 富的核心人员在团队中起着至关重要的作用n 2 1 他们可能不知道具体技术如何 实现 但却能够把握项目的重点和难点 知道从何处获得信息来解决问题 这就是管理的内涵 本章就是针对项目经理角色需要关注的管理性规范进行分 析阐述 所有团队成员都必须配合项目经理进行管理工作的贯彻 1 3 2 1 1 客户需求的获取 第一节项目需求的确定 1 需求分析的重要性 不管何种类型的软件项目 我们最关心的是项目完成后是否能满足预期的目 标 实现预定的功能和性能指标 因此 前期的需求分析非常重要 任何理解 的偏差或者不完整都会直接导致项目的失败 因此 为了节约一点分析需求的 时间而导致软件质量低下是一种愚蠢的行为 它只能使我们事倍功半 本文建 议 在没有明确客户需求并预估工作进度的情况下 不要轻易的开展项目 因 为这样的盲目性会给团队造成巨大的压力 一般的流程是先做需求分析 初步 分析 大致估计开发时间 然后待项目正式开始后进一步深入分析需求 14 1 2 做好需求分析的前提 了解客户应用环境 必须了解客户要开发的项目目标是什么 这样才能 有的放矢地进行分析和设计 市场主流与技术主流的了解 应该抽出一定时间来做市场和技术调研 如是否存在同类系统 有哪些优缺点 主流的解决方法是什么 有哪些 现成的工具包或开源代码等 可根据项目规模自由制定时间 根据经验 大概用预定项目周期的十分之一左右比较合理 客户现有需求的总结和潜在需求的挖掘 应尽力挖掘客户的潜在需求和 未来可能会进行的系统扩充要求 以便为项目的深入发展奠定基础 举 第8 页 需求分析的确定与过程综合管理 个例子 客户如果想对数据库进行查询操作 那他很可能还需要检索或 组合查询 甚至升级系统到较大规模 3 需求分析的人员分工 除了市场人员以外 有丰富项目经验的团队管理人员能对项目整体规划提出 切合实际的意见和相对准确的进度估算 从而为项目争取合理的资源和时间限 制 另外 一个软件从需求分析 设计 编码 到测试 调试 封装发布及后 续的技术支持 这是一个完整的过程 出色的测试经理可以对项目功能需要的 测试时间 大致的工作量做出估算 进一步帮助制定项目的进度和周期 因此 在需求分析阶段 市场 技术和测试人员分别担当着不同的任务 应当共同协 作完成这项工作 4 需求分析文档的内容组织 需求分析阶段通常需要完成项目建议书 p r o j e c tp r o p o s a l 市场与技术调研 报告 m tr e p o r t 需求变更风险分析 r i s k sl i s t 和需求分析说明书 r e q u i r e m e n ts p e c i f i c a t i o n 但是 针对中小型的软件项目 尤其是对文档要 求并不严格的项目来说 通常只需要写 份简单的项目建议书和需求分析文档 即可 如果项目规模更小 那可以考虑只把需求分析的一些要点内容记录下来 需求分析说明书需要具备以下内容 客户方的行业背景 实施项目的背景信息 特别是实施项目的主要目的 同样的系统在不同的客户环境中有不同的功能和性能需求 例如 普通 企业的办公自动化系统要求流程畅通和信息传递方便 但是金融行业首先要 求数据安全和信息传递的可控性 不同客户提出类似的需求时 必须清晰区 别客户应用目标的差别 客户方提出的基本功能目标 可分类 逐条描述 客户方对功能目标的性能要求 如处理速度 精度 稳定性 兼容性等 客户方对项目实施的要求 例如开发周期 发布形式 项目成本等 客户方的计算机软硬件环境 项目设计与实施过程中面临的各种约束 假定等 本文将在附录中给出具体的需求分析文档内容 必须注意的是 每个软件项 目的范围和类型不同 尤其是对于中小型软件项目来说 不需要严格按照模版 进行编写 而要根据项目的独特性进行取舍 第9 页 需求分析的确定与过程综合管理 2 1 2 需求到设计的跃升 1 系统设计的前提 在对项目进行系统设计时 必须已经对客户需求的细节进行了详细的调查和 分析 对相关领域的技术有了一定了解 特别是对技术重点和难点进行了仔细 分析和统计 如果设计有了丝毫偏差 后面的实现和测试工作将是徒劳一场 2 分工协作的工作模型 目前 很多软件团队是按照需求功能进行的人员分工 团队成员可能需要独 立处理界面 算法 数据库 网络传输等的部分内容 但是 不同技术人员在 自己负责的模块中 技术优势和劣势相对明显 这样整合起来的系统就是一个 水平不均衡 技术实现方法不一致的糟糕系统 而且 由于团队成员缺乏交流 数据结构和接口的定义容易出现混乱 为系统的整合造成了很大困难 显然 上面的分工模式存在很大的问题 本文建议另一种团队成员的协作分 工模式 按照技能水平进行分层协作 具体来说 就是将系统按照使用技术 的不同进行工作分配 比如分配专人负责界面设计 流程控制 底层数据库和 相关接口设计 网络传输 当然 这里指的专人可能是一个小组 小组内的 成员再按照这种方式进行分工 图3 1 软件团队的人员分工 这样进行人员分工的好处在于 不再要求技术人员有全面的技能 充分发 挥个人强项 系统风格和技术实现方法统一 整合容易 容易拓展进行大型项 目 这种分工耦合紧密 它可能一定程度上限制了团队成员的能力成长方向 但通过提高内部的交流和学习风气可以保证个人成长和团队发展相互协调 第1 0 页 需求分析的确定与过程综合管理 3 系统设计的分层 针对上面的协作分工模式 在进行系统设计时就不能简单的堆砌系统需求 而要按照 需求纵向划分 设计横向汇总 的方式进行抽象 体现设计的价值 客户往往关注的是系统的应用流程 怎样操作 而开发团队关注的则是控制 流程和数据流程 数据在系统内怎样存放 通过哪些控制怎样在系统内转移 处理 举例来说 一个办公自动化系统的用户登录功能 客户仅仅需要知道 输入正确的用户名和密码后可以进入系统 而开发团队所要关注的则是 界面 颜色 风格及按钮的摆放位置等 控制规则 这里可以理解为数据校验 简单分为 表3 1 用户登录控制规则 编甓船笋名 i 鎏密羯 二 一姆 l 正确 正确显示登录成功 2证确错误 显示密码错误 3 错误错误显示用户名错误 数据库存储 用户表的格式 例如 表3 2 用户数据表 编攀i角旁名 豢 密礁权限 t o m 普通用户 2j o i n 高级用户 3 a l i c e网管人员 可以看出 针对客户的简单需求 在开发过程中将其拆解为了几部分内容 同理 针对其他需求 我们也需要进行类似的拆解 然后将拆解后功能类似的 部分进行合并 组成单独的设计模块 交给专门的负责人员进行实现 衙求 筹且 糙计 图3 2 需求到设计的跃升 第1 1 页 需求分析的确定与过程综合管理 4 设计文档的内容组织 需求分析是从客户角度进行分析 着重在系统的功能说明 而系统设计则是 一个从内部解析的模块划分过程 设计类的文档主要包括系统概要设计说明书 s o f t w a r eg e n e r a ld e s i g n 和详细设计说明书 s o f t w a r ed e t a i ld e s i g n 概要设计 包括项目背景介绍 总体设计 接口设计 属性设计 系统 数据结构 运行设计 系统出错处理 开发环境和系统调试与测试方法 详细设计 包括编写目的 软件结构 公共数据结构 具体模块说明等 本文附录给出了详细的文档清单 可以根据实际项目规模对设计文档内容进 行取舍 必要时还要加上数据库设计说明 用户界面设计说明等 2 1 3 案例分析 案例 t y p e r e a d e rw e bs e r v i c e 项目的人员分工 项目目标是为o c r 软件t y p e r e a d e r 提供网络服务进行框架搭建和技术尝 试 团队共三人 一人负责用户和管理员界面设计 一人负责总体流程设计和 接口设计 一人负责数据库设计和大部分代码实现 结果表明 这样的设计和 分工模式保证了项目流程的完整和技术风格的统一 非常好的完成了项目任务 2 2 1 配置管理概述 第二节配置管理 先看一个例子 一个小公司的项目经理带着几个人研制了一种图形压缩算 法 并成功实现 老板扩充团队 将模块整合到行业应用系统中 几个月后公 司进行系统升级 新增功能 采用第三方控件并实现跨平台操作 软件开发到 第二版 推向市场后备受欢迎 某大公司将其收买 并派来专门的部门经理 扩充团队到几十人 准备推出软件的新版本 在这个过程中 系统的复杂性和 项目环境发生了很大变化 如何应对这种复杂的变更为我们提出了严峻的考验 1 配置管理的概念 配置管理工作非常复杂 经过多年研究和探讨 得出以下普遍认可的定义 配置管理 协调软件开发过程 使得各种混乱和错误减到最小的技术 叫 第1 2 页 需求分析的确定与过程综台管理 做软件配置管理 它是一种标识 组织和控制修改的技术 目的是使错误达到 最小并最有效地提高生产效率 1 刘 配置项 处于配置管理之下的软件或 和硬件的集合体 比如开发中的 各种文档 源代码 数据等口 可见 配置管理可以理解为对系统配置项进行跟踪和控制的一套规则 它是 支持质量保证工作的核心 是一种凌驾于其他管理规范之上的规范 作用在整 个开发过程中 规范行为 记录历史 以保证软件开发过程的正确和可控 2 配置管理的主要活动和功能 6 1 6 1 7 1 综合c m m 和i e e e 等各个体系的配置管理内容 其活动主要包括 配置标识 找出需要管理的配置项 将其加以记录使其受控于配置管理 配置控制 对配置项的变更进行评估 协调 决策及实现等 状态报告 记录各个配置项的变化状态 从而记录整个软件的变化过程 配置审核 验证软件系统满足规格说明书和文档中的对配置项的要求 在软件开发过程中 配置管理具备版本控制 1 9 变更控制 b u i l d 管理 过程控制和状态查询报告等功能 结构复杂 规模较大的软件开发通常需要一 个配置管理经理 p r o j e c tc o n f i g u r a t i o nm a n a g e r 和配置管理小组协作完成这项 工作 而中小型软件开发并不需要这么严格地遵循琐碎的条条框框理论 所以 项目经理通常会兼任配置管理经理的职责 负责监督和维护整个开发过程的有 序进行 2 2 2 配置管理的原则和方法 1 配置管理的具体工作 对外 对客户信息和数据的配置管理 首先 应该对客户需求的分析 跟踪和变更进行控制 记录不断改变的客户 需求和软件团队对客户需求在不同阶段的理解程度 可以通过对需求分析文档 进行版本控制 电话 邮件联系 会议记录等方式进行记录 并要时刻关注新的 需求是否引起了系统设计的改变 通过对设计文档和实现方法的版本控制 内 部团队交流 工作日志或者里程碑报告等手段进行记录 其次 还应对客户数 据的获取 使用和版权保护进行管理 软件团队必须对从客户方获得的一切文 档 数据 案例 工作流程介绍 邮件等内容进行全面妥善的保存和审查 同 第1 3 页 需求分析的确定与过程综合管理 时 签有保密协议的内容要针对成员给予不同的查看 使用权限 尽可能避免 泄露 在整个软件生命周期中 客户方的信息和数据理论上不应有任何修改 对内 软件工程环境的配置管理 这部分工作非常复杂 包括对各类文档 代码 接口 结构的版本控制 b u i l d 环境的统一管理 各里程碑的监控和总结等 控制文档版本的方法之一是规范 文档命名体系 在文档名称后面辅以适当的版本号 或者在文档前面添加修订 记录 以维护其历史档案 还可以将其和同版本的代码一起放到配置管理库 以不同的版本号标记 另外也可以用w o r d 自带的版本控制功能 至于重要的接 口变化 结构调整等 可以在更新设计文档的版本时予以标识 也可以专门建 立相应的版本控制 只要能达到可以追溯 回顾的目的即可i 2 0 系统的集成b u i l d 应该派专人负责 或者由项目经理承担 因为各人工作进 展不同 同时又需要相互协作 比如对全局数据结构 变量的更改 使用等 每b u i l d 一个新版本时都需要冻结当前的代码状态 不能任意修改 如果不统一 控制很容易出现混乱 因此 各部分代码在联合b u i l d 新版之前需要统一汇总到 一个人 在b u i l d 完成之前 其他开发人员可以做一些相关的技术尝试 另外 b u i l d 环境应尽量贴近客户使用环境 以避免由于开发环境不同使得软件发布时 客户不能正常使用 最好能提供一台专门用于系统集成b u i l d 的机器 系统的开发是循序渐进的 把整个开发过程分为几个大的阶段 以实现某些 功能为目标 每完成一个阶段的工作即为达到了一个里程碑 这样做的好处在 于可以有效的控制项目进度 同时可以鼓舞团队 对里程碑的监控和总结就是 指我们完成了一个阶段性任务后 要对己完成的工作进行总结 提交里程碑报 告 内容主要包括完成了什么功能 还剩多少尚未解决的问题等 并且要对当 前的一切系统配置情况进行较为详尽的说明 比如有何文档 数据 代码 当 前的版本情况 团队各成员所做的工作 所用时间 测试情况等等 系统开发 到最后 我们就可以有几份这样的资料 可以轻松的回顾整个开发过程 如果 不幸出现了问题 还可以追溯是哪个阶段的问题 回退到上 个乎确的里程碑 2 配置管理的工作形式 以文档为管理目标 文档是一个软件项目的灵魂 在项目开始时就要定 义好文档集合 由谁在何时进行编写 在开发过程中 要控制好文档版 本 及时记录项目历史 以代码 数据 接口为管理目标 预先设计好代码库格式 划分不同的 第1 4 页 需求分析的确定与过程综合管理 目录 严格控制版本变化 对接口和结构的管理要遵循 实现符合设计 的原则 保证结构完整 另终还要对代码和数据的访问权限进行分配 以交流 记录为主要内容 定期的客户交流可以帮助控制需求变化 及 时做出项目调整 可以通过文档或者完整的邮件备份形式对客户信息进 行收集并管理 团队内部也要经常进行交流讨论 保证项目的顺利进行 3 配置管理的原则 完整性 不是只有文档和代码才属于配置管理的范围 客户交流信息 需求变更与设计变化等同属配置管理 层次性 配置管理人员需要在配置管理上花费很多精力 但所有的团队 成员都必须严格遵循制定的配置管理规范 这样才能到达目的 具体性 只注重形式是毫无意义的 更要知道具体工作怎样做 对数据 结构 接口体系 应用流程改变进行有效的控制和管理才是工作的核心 4 配置管理的工作方法 建立统一的命名体系 项目名称必须在软件生命周期开始时就确定 包括中 英文命名 所有项目 成员以后都要遵照这个名字工作 其他规范可参照下面的规则 1 代码文件命名 一律8 3 格式 u i 代码除外 具体模块可参照系统设 计的模块名 2 项目文档命名规则 a 一律以英文或中文命名 不得混杂 b 命名格式 项目名称一文档类型一文档具体名称一版本号 d o c 3 工作日志与报告类 a 工作报告每周提交 命名格式为 日期一姓名 r e p o r t b 日期格式 y y m m d d c 姓名格式 姓名或邮箱帐号 此处邮箱指开发团队内部的统一邮箱 4 邮箱命名 a 邮箱帐号一律用小写拼音 中间无空格 b 两字姓名为名在前姓在后 后面是统一的内部邮箱名 如 张帆 f a n z h a n g i m i n a n k a i e d u c n 刘颖 y 也g l i i 迪 垒塑蜒 血 鲤 c 三字姓名为名字缩写在前姓在后 后面是统一的内部邮箱名 如 李建华 j h i i 世 n 塑k 堑 堕堕鲤 赵庆云 q y z h a o i m i n a n k a i e d u c n 第1 5 页 需求分析的确定与过程综台管理 注 为避免信息交流延迟或者信息泄漏为项目带来的风险 不建议团队 成员使用外部的免费邮箱 5 开发团队人员的机器名称 一律按照邮箱帐号命名 例如 张帆的机器 名称为f a n z h a n g 赵庆云的机器名称为q y z h a o 建立统一的文件夹结构 文件夹中存放所有项目相关资料 应在项目开始时就定好 不确定的地方可 暂时留空 分工不同的成员的文件夹内容可以不同 但并不影响结构的统一 建议使用英文进行文件夹目录的命名 具体结构可以参照图3 3 的定义方式 l p 抽 t l 一 p t j e c tn 图3 3 文件夹结构示例 明等 建立规范的版本记录习惯 团队成员应养成良好的自觉进行版本记录的习惯 包括各类文档 代码 记 第1 6 页 需求分析的确定与过程综合管理 录和报告等 表现形式可以多种多样 如利用日期标明 添加修订记录 版本 号等 但必须妥善保管好以往的版本 可以起到重要的回溯功能 可以将阶段 性的版本放入统一的配置管理库保存 或者简单的放入代码库 对于比较复杂 的项目 有时还必须定期刻盘保存 图3 4 是一个文档修订记录的例子 r 删s i o nh i 呦噬 v e l 1 0 nd a 慷a u t h o z s d e s c r i p t i o no f v e l s i o n c o m p l e 抛d l02 0 0 3 0 4 l4 黝 t a n c r e a t ed r a r 202 0 0 3 m 4 2 8 舔靴弱a 靴l i m o d i 如 212 0 0 3 0 5 0 2 确鹞姊女蛳g l iu p d a t ef o f r e q u i r e m e n tc h a n g e 图3 4 文档修订记录示例 这是一份软件发布文档的修订记录截图 可以看出 此文档于2 0 0 3 年4 月 1 4 日由h u i t a n 完成初稿 2 0 0 3 年4 月2 8 日由x i a o g u a n g l i 修改到2 0 版本 后由于需求变化 x i a o g u a n g l i 又在2 0 0 3 年5 月2 日修改 目前是2 1 版本 严格的版本号由主版本号 次版本号 里程碑编号 b u i l d 次数四部分组成 l 搦 醺本o ji 骘圈 扳邋 j 一 匪互 竺蛩 版本0 一一 淑救4 峙 峨 卿蹯 i 一 t 图3 5 版本号组成 主版本号和次版本号通称外部版本号 主版本号由系统特征决定 次版本号 由系统功能决定 当系统有了较大改变 如由单机系统升级为办公自动化系统 又升级为w e bs e r v i c e 系统 这时可将主版本号升级 如1 0 2 0 3 0 而如果 系统新增了一些功能模块 而体系结构改变不大 可以升级次版本号 如 1 0 1 1 1 2 内部版本号由里程碑编号和b u i l d 次数组成 软件系统发布时通 常只需表明外部版本号 内部版本号通常为开发调试时使用 建立层次分明 交流通畅的项目监控机制 为了保证项目一致性 需要指定各级负责人 提供唯一的信息出口 如对外 第1 7 页 需求分析的确定与过程综合管理 与客户联络 对内进行新版本b u i l d 等 都需要专人负责 不能越权进行 另外 明确审核流程也是非常重要的 可以如表3 3 建立一个简单的审核文档表格 表3 3 审核文档表格示例 黧i 测谶ip 盼闯i 藏 錾糠氍l 滚滚 预期 状态 躺景灌穆鬻 随番i籀窿薰曩i 时间 l项目1 2 项目l 3项目2 在表3 3 里 我们可以将同时进行的各个项目的各项功能指标填进去 在适 当的时候由q a 人员和开发人员协作填写 互相提醒监督 2 2 3 配置管理的工具和技巧 1 配置管理工具的选择 实施配置管理非常容易出错或引起混乱 因此 自动化的配置管理工具越来 越受到关注 比较有名的有r a t i o n a lc l e a r c a s e c v s m i c r o s o f tv i s u a ls o u r c es a f e 等 对于中小型软件项目 本文不建议使用过于庞大的管理工具 因为很可能 需要耗费过多精力去学习使用 这对中小型软件团队来说是得不偿失的 当然 可以根据项目规模合理的选择配置管理工具来提高效率 例如可以在 进行版本控制时使用v s s 在进行跨平台项目的开发时使用跨平台的管理工具 c v s 在进行比较小的项目时甚至用w o