2018-03-21 | 分类作业 | 标签博客

系统分析与设计 Lesson 2

1. 简单题

· 简述瀑布模型、增量模型、螺旋模型（含原型方法）的优缺点。

瀑布模型

优点：

降低软件开发的复杂程度，提高软件开发过程的透明性，提高软件开发过程的可管理性。
推迟软件实现，强调在软件实现前必须进行分析和设计工作。
以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，保证了阶段之间的正确衔接，能够及时发现并纠正开发过程中存在的缺陷，是产品达到预期的质量要求。

缺点：

强调过程活动的线性顺序。
缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。
风险控制能力较弱，失败风险较高。
软件活动是文档驱动的，当阶段之间规定过多的文档时，会极大地增加系统的工作量。
管理人员如果仅仅以文档的完成情况来评估项目完成进度，往往会产生错误的结论。
不适应用户需求的变化。

增量模型

优点：

将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展。
以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。
开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。
提高系统的稳定性和可维护性。

缺点：

增量粒度难以选择。
确定所有的基本业务服务比较困难。
缺少一定的需求分析。
模块间的设计不当，后期修改代价会很高。

螺旋模型（含原型方法）

优点：

引入了明确的风险管理。
设计上的灵活性,可以在项目的各个阶段进行变更。
以小的分段来构建大型系统,使成本计算变得简单容易。
客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。
随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。

缺点：

风险分析需要相当的成本耗费。
失败的风险分析可能带来更大的风险。
迭代次数不确定，也无法确定产品发布的日期。
不适合大团队合作。
有时客户会对风险分析不买账。

· 简述UP的三大特点，其中哪些内容体现了用户驱动的开发，哪些内容体现风险驱动的开发？

三大特点

用例/客户驱动 Use Case Driven

用例

用例是一系列行为的散文表述。
行为是由一个或多个行动者（人或非人）和系统本身执行的。
这些行为对一个或更多的行动者来说是有价值的，可以帮助他们达成他们的目标。

用例是站在用户的角度上使用自然语言来表述的，它必须可以被所有利益相关者所理解。

用例驱动意味着开发团队要依据客户需求进行开发，并且在编码和测试阶段也要不断收集和明确客户的需求。

架构为中心 Architecture Centric

软件架构是关于：

软件系统的整体结构
系统的结构元素（模块）和它们之间的接口
这些结构元素之间的合作和它们的预期行为

架构为中心：软件架构提供了其他所有发展演变的中心观点

为系统提供了一个蓝图
为开发过程提供一个组织框架，注重改善系统的质量来发展完善系统
鼓励重复利用有效的结构模块

迭代和增量 Iterative and Evolutionary

迭代和增量式开发允许开发初期的知识准备不完善。

迭代和增量式开发有以下特点：

系统架构逐步趋向稳定
有效管理需求变化
持续集成
尽早接触整个系统
在线的风险评估

迭代和增量式开发是在固定的迭代周期前提下，每次迭代周期内，依据需求提供系统原型或是对原型进行修改和完善，并在此过程继续明确需求，最终需求趋于稳定，系统呈增量式增长。

在三大特点中，用例驱动体现了用户驱动的开发（依据需求开发），以架构为中心体现了风险驱动的开发（设计一个架构，开发有中心点），迭代和增量式开发则包括了用户驱动和风险驱动的开发（管理需求变化、在线的风险评估）。

· UP四个阶段的划分准则是什么？关键的里程碑是什么？

UP四个阶段

初始阶段 Inception：大体上的构想、业务案例、范围和模糊评估。
细化阶段 Elaboration：已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数需求和范围以及进行更为实际的评估。
构造阶段 Construction：对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署。
移交阶段 Transition：进行beta测试和部署。

划分准则

依据UP的软件生命周期时间和每个阶段的关键里程碑来划分。每个阶段结束于一个关键的里程碑，并在每个阶段结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意，可以允许项目进入下一个阶段。

关键的里程碑

初始阶段里程碑：

生命周期里程碑，包括一些重要的文档，如：项目愿景（Vision）、原型用例模型、原始业务风险评估、一个或者多个原型、原始业务案列等。需要对这些文档进行评审，以确定正确理解用例需求、项目风险评估合理、阶段计划可行等。

细化阶段里程碑：

生命周期体系结构里程碑。包括风险分析文档、软件体系结构基线、项目计划、可执行的进化原型、初始版本的用户手册等。通过评审确定软件体系结构已经稳定、高风险的业务需求和技术机制已经解决、修订的项目计划可行等。

构造阶段里程碑：

初始运行能力里程碑（发布）。包括可以运行的软件产品、用户手册等，它决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运行。

移交阶段里程碑：

产品发布里程碑（最终产品发布）。确定最终目标是否实现，是否应该开始产品下一个版本的另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段相重合。

· IT项目管理中，“工期、质量、范围/内容”三个元素中，在合同固定条件下，为什么说“范围/内容”是项目团队易于控制的。

　　工期是指完成项目的时间，这在项目计划阶段，签署合同前，项目团队和客户会协商达成一致；质量包括了在项目开始前客户提出的对项目的预期需求以及在项目结束后的验收满意程度；范围/内容则是包括项目开发团队对项目系统所设计使用的框架模块和功能代码等等。

　　前两个元素在合同固定条件下，因有客户的参与，所以项目团队不容易控制；而“范围/内容”则可以根据项目团队本身自己的资金状况、人力资源情况和时间安排，对项目系统进行相应的设计和编码，比如在资金或时间资源不足情况下，项目团队可以通过使用减少或修改项目系统的功能模块但又能满足客户基本需求的方法，在达成项目目标的同时，渡过危机。所以，”范围/内容”是项目团队易于控制的。