分析软件体系结构SoftwareArchitecture.ppt

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 引子 作为一个项目经理，我遇到的最大挫折是，当我知道我们的开发小组完成了一项出色的工作，生产出一个出色的产品时，但是该产品在市场上仍然没有显著的影响。在某些情况下，这是因为销售人员还没有准备好出售该产品，或者他们并不了解该产品的潜能。一段时间以后，我试着不再为那些不能为我所左右的事情而担心了。如果你的开发小组达到了你在项目之初所建立的目标，包括成功地实现预想的体系结构，这就有足够的理由来庆祝你的成功 在进度、功能和质量之间进行权衡 项目管理包含着做出权衡。你可以在项目之初建立一系列目标，但是你每天都需要对那些与目标相抵触的事物做出决策。最通常的权衡包括进度、功能和质量 识别不成功的项目是很容易的，它们是 推迟了原定的交付日期 没有满足用户所期望的功能 用户在产品中发现了很多错误 项目经理可能做出的解释 我没有合适的人员分配给这个项目 市场销售部门过分宣传了产品的功能，做出了我们无法实现的承诺 我们符合预算和进度，但是也必须对期望的功能作很大削减 我们没有分配足够的时间来进行测试 最初我对这一过激计划提出了异议，但并没有被接受 成功项目的定义 几乎很少有哪个项目在进度、功能和质量等方面满足所有的目标 经验表明，能够成功地在进度、功能和质量三个方面中至少满足两个方面目标的项目也很稀少，这样的项目可能更应当被认为是一个整体性的成功 例如，一个成功的项目，应该符合其进度，还提供了绝大多数计划中的功能（例如90%~95%的特征），并且在系统测试和现场测试中都显示出具有好的质量（例如，在现场测试中只发现极少或者没有严重的缺陷） 不要混淆项目成绩与个人表现 表现差劲的人可能有时候很幸运地被委派到一个成功的项目中。一定要细心区分所有小组成员的相对贡献，不要想当然地认为，如果项目是成功的，那么所有人都做了出色的工作 度量小组成员的贡献 作为一名项目经理，你将被要求度量你的小组成员的相对贡献 许多个人表现的评估服从一种目标管理（MBO）的形式和生命周期。有了MBO，你可以在复查时期的开始或者前一个复查时期的结尾，连带地确定和讨论个人的目标 个人的表现：是否符合进度日期，是否实现了期望的功能，是否开发了高质量的代码。此外，还有一些“软因素”，例如团队精神、有效的沟通、业务水平的提高等 员工更替 项目是否成功的一种指示可以由小组成员来决定。忍受了一个艰难的或者不成功的项目的小组成员也许会以离开公司来表示他们的不满，这称为“以脚投票” 员工更替度量标准经常能够从整体上衡量出小组成员是否喜欢他们的项目工作 过去12个月中离开的员工数/12个月以前的员工规模 在某些情况下，员工更替率高是由于艰难的商业环境所导致的解雇。这种员工规模的缩减通常会对解雇之后还需要延续的项目产生负面的影响 解雇员工或者高员工更替率的一个更大的影响，就是软件项目失去了其延续性 每个发布了的软件产品，只要用户持续使用它，就需要得到维护。如果需要的话，公司保留该产品开发的原班人马总是很方便的，这样，即使很棘手的用户需求变更也可以得到满足 内容 内容简介 以体系结构为中心的软件项目计划 全局分析 管理期望 项目组织 建立项目文化和小组 软件项目经理的角色 权衡和项目决策 增量式开发 创建可视性与避免意外 在激烈的竞争中保持冷静 需关注的度量 什么是“出色的工作” 总结 分享最佳实践成果 任何一名软件工程的研究者所遇到过的主要和长期存在困难之一就是相对缺乏实践 在这里提供的技巧都是基于逸事一样的经验，被认为是最佳实践 有关软件实践方面的部分困难是，软件开发是一个劳动力密集型的工作，会延续很多个月甚至很多年。让学生来完成的小规模软件开发任务，这种试验很少能模拟出真正的产业环境 想在更好地管理软件项目方面取得实质性进展的唯一方法就是共享最佳实践，这已经在很多希望从他们自身的成功和失败中学习经验的公司中实施了 方法优点 作为一个主要的工具，软件体系结构对于管理项目起着核心作用。在制定开发进度表和吸纳大量开发人员之前启动高层体系结构设计和项目计划 项目组织 全局分析 权衡决策 项目的可预测性（增量开发） 软件质量（增量版本测试） 项目经理的信誉 对于任何一名软件工程师来说，最大的回报就是看到他的产品正在被其他人所使用，即许多人在他们的日常工作和生活中能够使用你所开发的软件系统 “销售是我快乐的源泉，而金钱是对我的奖励。” ——Joe Girard，世界最伟大的销