~怪^_*兽~

摘要： 控制阶段图 6-1 控制阶段的任务和工件风险管理 开发期间要对风险进行监控，定期检查、更新和发布《风险列表》。质量管理 1） 评审 评审是质量保证的重要环节，原则上每个重要的工作任务或阶段结束前都必须经过评审，如：方案评审、计划评审、需求评审、设计评审和代码评审等，工作是否被通过、是否需要修改或重做均由评审结果决定，评审结果以《评审报告》的形式发布。 《评审报告》的内容包括：基本信息评审主题、时间、提交者、评审者等评审内容评审内容的列表和简述问答记录评审过程中重要的问答记录评审结论整个评审的结果，如：完全通过，无需修改基本通过，需要作小量修改，但不必再评审大体通过，需要作一些修改，之后... 阅读全文

摘要： 执行阶段图 5-1 执行阶段的任务和工件需求分析 分析产品的关键需求、对架构设计有影响的需求和风险较高的需求，直到分析的程度能开展足界面原型设计和架构设计工作。 《需求规格说明书》的内容包括：商业或业务需求从商业或业务角度宏观上对产品或系统的要求。它主要在宏观的层面归纳总结为满足客户提出的要求或赢得市场竞争所必须实现的功能、性能、质量等要求。做什么做的范围对结果的要求使用者需求从客户对软件产品或系统使用方案的角度出发，描述和总结使用者利用该软件产品或系统能够做的事或能够完成的任务。功能需求根据上述使用者需求列出的使用方案，列出开发者必须为软件产品或系统实现的功能。性能需求运行速度、容量、并.. 阅读全文

摘要： 启动阶段图 3-1 启动阶段的任务和工件产品领域研究 研究产品所在领域的状况，为项目论证提供依据。研究内容包括：产品领域的现状和前景产品领域的商业模式和业务流程产品的价值和盈利空间产品的特性和复杂度技术可行性研究 研究产品的实现技术，总结技术可行性。研究内容包括：类似产品的当前实现技术和技术趋势实现技术的候选方案各个方案的优点、成本和风险开发团队与实现技术的匹配情况项目论证 基于商业和技术等方面对项目的可行性进行论证，确定项目是否开展。如果开展项目，则进一步论证项目的总体方案。 论证的内容包括：商业可行性技术可行性当前产品与类似产品的比较项目收益和前景项目的成本和风险项目的总体方案确定... 阅读全文

摘要： 前 言 前一篇文章《软件开发基本原则》谈论了软件开发原则方面的问题，而本篇文章尝试谈谈软件开发中更具体的一些内容 —— 普通软件项目的开发过程规范。本座也知道，如果过程规范讲的太具体对谈论者来说是非常冒险的一件事情，它不像技术，对就对错就错，有一个客观的评判标准，别人想喷你也得自己先好好研究等拿到了足够的论据才能喷，但开发过程和项目管理就不同了，别人仅凭一点点所谓的管理经验甚至是主观推断就能喷得你体无完肤，摇摇欲坠 ~ 因为没有什么所谓的事实标准与放之四海皆有效的软件开发过程和项目管理方法。保守估计，100个人中至少有150种想法。本座也深知其中的凶险，因此避重就轻，从基本原理谈起，宏观的角. 阅读全文

摘要： 1988年，Peat Marwick针对600家成功公司的调查结果显示，35%的公司有过软件项目失控的经历。（Rothfeder 1988） 1982年，Allstate公司宣布其公司运营全部要实行自动化。他们启动了一个将耗时5年投资800万美元的大型项目，而在花费了6年和1500万美元后，Allstate公司重新调整了目标和最终期限，重新调整后的预算大约1亿美元。 1988年，Westpac Banking公司决定重新设计他们的信息系统。他们做了5年、8500万美元的计划。3年后，在花费了1.5亿美元却依然收效甚微时，Westpac Banking公司为了减少损失，取消了这个项目，并... 阅读全文

摘要： “回顾一下被选为‘最佳项目’的十个软件项目，如果说有所发现的话，那就是——最佳的项目一定是建立在最佳的软件开发基础之上的。我们都知道软件开发基础对于优秀软件的作用，但差别在于大多数软件的基础薄弱，这样不可避免地使自己陷入麻烦之中”（Bill Hetzel 1993） 本章的范畴只限定在确定软件开发的基本原则，解析他们是如何影响开发计划的，同时提供参考信息。本章书把软件开发基本原则实践分为三类：管理实践，技术实践和质量保证实践。管理的基本原则 管理原则由以下几部分组成：判定产品规模（包括功能、复杂度和其它产品特性）根据产品规模分配资源制定资源计划监控、引导资源以保持项目方向不会偏离1. ... 阅读全文

摘要： 大多数典型错误其表面都具有诱惑性，给人们一种诱人的前景，但通常却不能产生期望的结果。 “想挽救进度已经落后的项目吗？---- 给项目补充更多人员！” 下面分别按照人员、过程、产品和技术四个维度列出36个典型错误。人 员典型错误1：挫伤积极性 对人员不够关心和重视；过度的进度压力；缺乏激励；过分夸张的激励等。典型错误2：人员素质低 人员能力欠佳，工作效率低，甚至做多错多。典型错误3：对有问题的员工失控 不对有问题的人员采取措施是项目组成员对领导最常见的抱怨。典型错误4：英雄主义 强调个人英雄主义会导致发生额外的风险，也会削弱在软件开发过程中多个角色的合作。典型错误5：项目后期加入... 阅读全文

摘要： 前 言 前段时间一直在写技术方面的文章，现在想转转口味，从软件开发过程和项目管理的角度来谈论软件开发。本座也知道，从这两个角度来谈论软件开发对谈论者来说是非常冒险的一件事情，它不像技术，对就对错就错，有一个客观的评判标准，别人想喷你也得自己先好好研究等拿到了足够的论据才能喷，但开发过程和项目管理就不同了，别人仅凭一点点所谓的管理经验甚至是主观推断就能喷得你体无完肤，摇摇欲坠 ~ 因为没有什么所谓的事实标准与放之四海皆有效的软件开发过程和项目管理方法。保守估计，100个人中至少有150种想法。本座也深知其中的凶险，因此避重就轻，从基本原理谈起，宏观的角度阐述相关问题，尽量减少中弹的机会。欢迎大. 阅读全文

摘要： 现在我们看看一个实际的例子，从不同设计原则的角度来观察它的设计。这个例子是信息处理中心－数据传输控制组件的消息处理模块，首先看看它的结构图、类实现伪代码和主体程序伪代码： 图3-1 消息处理模块结构图程序3-1 类实现伪代码/////////////////////////////////////////////////////////////////////////////////// Command 类///////////////////////////////////////////////////////////////////... 阅读全文

摘要： 随着应用程序的规模和复杂度的增加，需要在更高的层次对它们进行组织。类对于小型应用程序来说事非常方便的组织单元，但是对于大型应用程序来 说，如果仅仅使用类作为唯一的组织单元，就会显得粒度过细。因此，就需要比类“大”的“东西”来辅助大型应用程序的组织。这个“东西”就是包 （package）。 本节描述了6个原则。前3个原则关注包的内聚性，这些原则能够指导我们如何把类划分到包中。后3个原则关注包的耦合性，这些原则帮助我们确定包之间的相互关系。 在UML的概念中，包可以用作包容一组类的容器。通过把类组织成包，我们可以在更高层次的抽象上来理解设计。我们也可以通过包来管理软件的开发和发布。目的就是... 阅读全文