软件工程概述解读.pptVIP

* GB8567目前最新的版本是2006年发布的【计算机软件文档编制规范】 为了描述软件生存期的活动，提出了多种生存期模型，例如： 瀑布模型、循环模型、演化模型、螺旋模型等。 * 不同模型包含过程不同，但所有模型都有系统分析（需求分析）、系统设计（概要和详细设计）、系统实现（编码及测试）、系统维护。 生命周期方法学是从时间角度对软件开发和维护的复杂问题进行分解，把软件生命的漫长周期依次划分为若干个阶段，每个阶段有相对独立的任务。采用该方法时一个阶段一个阶段地进行开发，前一个阶段任务的完成是后一个阶段任务开始的基础和前提，后一阶段是前一阶段工作进一步具体话。每一个阶段的开始和结束都有严格标准。 按照该方法，各阶段的工作自顶向下从抽象到具体顺序进行，就象奔流不息的瀑布，从高处依此流到底处。因而也叫瀑布模型。 * 敏捷开发的思想 -可以工作的软件胜过面面俱到的文档 文档对客户来说并不重要，用户需要的是一个能够运行，能实质解决工作中问题的可以工作的软件。 文档对开发团队也不重要，上白页的报告没有人愿意写，对团队来说最好的文档是代码和团队。 致力于提供可工作的软件，但并不是不要文档。敏捷开发会编写短小并主题突出的文档来描述系统的高层结构和设计原理。 敏捷开发的思想 -客户协作胜过合同谈判 软件开发的最终目标是提供给客户满意的软件，而只有客户才清楚怎么样才能满意，敏捷开发提倡客户和开发团队密切的在一起工作，并尽量经常性的提供反馈。各种不同的敏捷方法都会利用短期迭代，通过尽早提供可执行的软件来与客户频繁沟通和反馈，把问题及早暴露出来，以免隐藏的问题在后期造成更大的影响。 敏捷开发的思想 -客户协作胜过合同谈判 敏捷软件开发致力于客户协作，但为了双方的利益和需要仍旧需要进行合同谈判。敏捷软件开发中的合同应为开发团队和客户的协同工作方式提供指导，而不是试图去规定项目范围细节和固定成本下的进度。 敏捷开发的思想 -响应变化胜过遵循计划 计划赶不上变化，敏捷项目承认开发过程中的不确定性，所以不会在开发中制定长时间的复杂计划，而是制定细致度逐渐变低的计划。 构建计划，是建立在上一次迭代反馈的基础上。确保计划是灵活的并且易于适应商务和技术方面的变化。 敏捷开发的思想 -响应变化胜过遵循计划 计划不得考虑得过远。因为环境的变化会引起需求的变动；客户可能改变需求；即使熟悉需求且需求不会改变也不能很好的估算开发它们所需要的时间。 总体来说，敏捷开发方法是“规划—执行—调整”、“规划—执行—调整”……的迭代过程。 敏捷开发的原则 最优先要做的是通过尽早和不断交付有价值的软件满足客户的需要 -通过频繁迭代与客户形成早期的良好合作，及时获取客户的反馈来提高产品的质量。 敏捷团队欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户竞争优势。 -敏捷团队认为改变需求是好的事情，因为那些改变意味着团队已经学到了很多如何满足市场需要的知识。 敏捷开发的原则 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。 -敏捷团队不交付大量的文档或者计划，他们认为那些不是真正要交付的东西。他们关注的目标是交付满足客户需要的软件。 业务人员和开发人员应该在整个项目过程中天天在一起工作。 -软件项目不会依照之前设定的计划原路执行，中间对业务的理解、软件的解决方案肯定会存在偏差，所以该项目相关的人员之间进行有意义、频繁的交互可以在早期及时的发现并解决问题。 敏捷开发的原则 围绕被激励起来的个体来构建项目，给他们提供所需要的环境和支持，并相信他们能够完成工作。 -业务和技术是引起项目不确定性的两个主要方面，而业务和技术又必须由人来执行，人是获得成功的最为重要的因素，所以激励人来解决问题是解决不确定性的关键。 在开发小组中最有效并富有效率的传递信息的方法是面对面的交谈。 -首要的沟通方式是交谈，也许有文档，但不会包含所有的项目信息。 敏捷开发的原则 可以工作的软件是进度的主要度量标准。 -敏捷项目通过度量当前软件满足客户需求的数量来度量开发进度。它们不是根据所处的开发阶段、已编写的文档多少、结构代码数量来度量。 对卓越技术与良好设计的不断追求将有助于提高敏捷性。 -所有敏捷团队成员都致力于只编写他们能够编写的最高质量的代码。 敏捷开发的原则 敏捷过程提倡可持续的开发速度，责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 -团队不是以全速启动并试图在项目开发期间维持全速行进。他们以快速但是可持续的速度行进。敏捷团队会测量自己的速度，不允许过于疲惫。他们工作在一个可以在整个项目开发期间保持最高质量标准的速度上 敏捷开发的原则 简单，尽可能的减少工作量是最根本的。 -敏