软件工程工程流程完整版.docx

软件工程工程流程完整版.docx

《软件工程工程流程完整版.docx》由会员分享，可在线阅读，更多相关《软件工程工程流程完整版.docx（12页珍藏版）》请在冰豆网上搜索。

软件工程工程流程完整版

用户实例（用例）这个概念是在1986年被IvanJacobson首次提出的，并一直沿用至今，并在1999年被Booch被定义为“对一系列结果行为的描述，是一种能产生直接观察行动的系统行为”。

时至今日，用例不仅仅应用于企业需求分析，还应用于设计并建立大型软件系统上。

用例模型描述了整个系统的行为模式，它主要包括：

1.角色列表：

模型中参加的人员及其关系；

2.用例包：

表示用例之间的关系层次；

3.用例图：

是用例模型的图形/图像表征；

4.用例文本：

包含用例的文档；

5.用例视图：

帮助读者从不同角度理解模型。

而要建立一个大型的程序的过程中用例图也要进行详细的分析才行，只有每个成员都通过用例图对整个软件有了大致的了解，用例图才是成功的，软件实施之后的问题才会尽可能的减少：

1.针对的对象：

需求工程师，软件工程师，顾客；

2.各方对用例图的要求与认识：

需求工程师：

要理解软件的需要和可实施性

软件工程师：

想了解问题的广度和范围，以及顾客和最终用户的需求

最终用户：

要确保他们的需求得到满足

顾客：

要确保对项目团队要求的理解以得到一个可行的产品

开发团队：

想了解他们需要建立的是什么。

3.成功保证：

项目团队有一个好的，项目的功能要求的可行的描述。

客户和承包商双方理解并同意的要求。

4.开始时刻：

要求工程师决定开始收集和征求客户的要求

在了解了以上这些基本的需求信息后，我们的前期准备工作也可以开始了，整个过程从开始到结束的基本框架大概是：

A.初始化步骤

0.客户的问题及需求描述

1.需求工程师和架构师定义系统边界

2.需求工程师组织团队（要求工程师）

3.需求工程师建立问题域的对象模型

B．实施过程

4.需求工程师确定用例图中角色

5.需求工程师确定用例

6.需求工程师组织并建立模型架构

7.软件工程师建立初步模型

8.需求工程师描述用例

9.需求工程师重构模型

C.配套支持措施

10.需求工程师验证和确认模型

11.软件工程师确定未来的需求

D.结束

12.需求工程师决定何时停止

接下来我们一步一步进行详细解释：

A.初始化步骤

步骤一、定义系统边界：

在开始之前做好相应的准备工作和决策非常重要，首先要做的是建立一个初步的框架，这是一个重要的步骤，因为它可以慢慢发掘出软件的本质要求，这一过程中要明确“我们要解决什么问题？

用户是哪些人？

我们有什么功能性需求和非功能性需求？

”等等。

这里举例为证，一个警察部队的指挥与控制工程软件的分析：

1.问题描述：

问题1：

发生突发事件警察来的时间慢；

问题2：

警车的位置取决于他们的无线电和电话描述，并不是很准确；

问题3：

警车不定期注册，警车和他们的管理是一个手动操作，容易有一些失误。

2.利益相关者：

居民：

居民确实会获益，但在公共设施中他们没有付出相应的成本代价，所以不算在建立过程中；

顾客代表：

角色是顾客，确保项目的成本和范围不和预期有太大出入；

用户代表：

角色是最终用户，确保系统的交互设计将有利于最终用户。

3.用户需求：

任命指挥官，轮流负责本区的整体运作；

分巡逻警察，轮流进行特殊的值班巡视；

任命物品主管，负责所有设备包括警车和各种探测器（相机，雷达等）。

4.新系统的功能：

新的紧急操作中心系统以提高警报速度，需要用导航地图等很清晰明确的方式提高访客操作速度和警车调度；

值班人员的任务由于数据更加精确而提高，需要位置自动更新并定位，自动报警并生成统计等详细报告；

区主管和警察局长可以发现问题，并统计人员的工作量，需要趋势和分布状况报告以实行对问题的高级别审查，以及事件分析（包括空间分析）工具支持问题的模式识别。

物流经理的工作变得更有效，需要在应服务时间/使用的基础上使用自动以及所有系统生成的设备类型服务的历史跟踪报道；

巡逻警察的工作更容易、更有效。

需要组合导航系统，在提高了调用的响应时间的同时还可以在线访问许可和登记数据库，提高了跟踪和识别罪犯的能力。

步骤二、组织队伍：

第二步进行开始前有组织的的建模工作。

对于队伍的第一个方面是设计团队规模和总的设计队伍数量，在这两种情况下，可取的做法是保持尽可能小的尺寸，一般都是每组两到三个人，有需求的话再多设计几个组，这样既可以保持软件的全面性和一致性，又可以将任务系统细化。

而像原文中提到的例子，项目经理有10个人，他们带着150个人去做任务，结果自然是大家都偷懒，进程一拖再拖，最终公司损失了几百万美元买了一个教训。

第二个方面是团队协作，每个小队应配备不同特长的人相互协同分工，以求从各个方面理解客户的需求和软件的功能。

在做大型项目时，平衡每小组的人数问题很是微妙，可以先让一个小组先建立一个基本的用例架构，然后其余的小组经过分工在架构的基础上添加一些丰富的东西，这样做出来的用例图更直观丰富。

在大型项目中另一个问题也十分重要，这就是重叠问题，因此需要真正有大局观并有专业知识的负责人员安排各个小组的分工合作，以保持用例的一致性并减少重叠。

步骤三、建立问题域的对象模型（PDOM）：

PDOM通常是一组UML对象图首先描述在问题域中的各种对象之间的关系，其次是确定在每个图中的解释条款/对象。

下面还是展示的警察其他命令与控制的一小部分为例：

在这个图中各方关系都有所体现，而且清晰明了，为后面继续软件的开发过程奠定良好基础。

PDOM作为系统的概念与对象的词汇，可以起到帮助团队的沟通的作用，也有助于实现更大的用例本身之间的一致性。

PDOM是三个类模型过程操作中的其中之一，另外两个是分析类模型（使用其他的用例模型作为源）和设计类模型（即设计模型应用程序所使用的实际的类）。

B．实施过程

步骤四、角色的寻找

这里的角色是指相对于系统下的一个用户或外部系统，通常寻找角色本身不是目的，而是从中确定用例，为用例图的设计开始一个好的起点。

一个重要的问题是角色和职位的区别。

在用例建模的前期从确定主要演员的职位开始是非常方便的，唯一的问题是这通常是不正确的——因为一个人可能扮演几个角色，为了解决这个问题，最好是保持工作职务/角色矩阵，这样的角色的业务使上下文不丢失并让真正的角色用于真正的使用，这种关系也可以在角色图中使用泛化关系。

在上面的警察的例子中，值班人员要实时了解其他成员的位置，这就要求其他成员的位置要实时进行更新，然后再在地图上标记出来，可画出它的用例图：

步骤五、寻找用例：

这一步是一个使用案例的最重要的活动模型。

在初始的状态，并不需要找到所有的系统用例，但而要找到足够的有意义的用例，并给一个很好的概述系统。

然后这个概述系统可以用于识别风险因素，并建立了一个初步的候选人的体系结构。

寻找用例大致有四种主要的方法：

1.场景驱动：

他是受传统的面向对象的方法启发。

该方法是研究的主要是参与角色的名单，从例如“参与者需要什么样的服务？

他们会给出什么信息？

”等等问题中寻找线索。

2.角色责任：

它是情景驱动的启发式变异，要求每个参与者，找到自己的角色和责任，和其他角色合作以完成任务。

以例确定生产任务并发现其中的联系作为结果。

3.非结构化聚集：

它是基于非结构化的文档或研究RFP RFP等的的任何需求，从而得到可以主动被视为候选人的用例。

它主要研究用例的特异性和非功能需求。

4.任务分解：

是有点类似于传统的分解，开始一个任务的目标，开始分解过程，这一直持续到作为一个用例的输出规范而不可分解，这种方法的好处是对主要的功能性的任务有较好的分析描述。

该用例图中在总部的值班人员将巡视的信息发出，各分区的巡视总负责查看并了解情况，总部值班人员还可以根据具体的突发事件做出紧急调整以及预警方案。

步骤六、建立组织模型：

组织模型是一个简单的任务，也是最重要的一步，对于该模型的可管理性而言，读者需要一个简单的的方式来浏览，更重要的是要理解它。

组织模型可以帮助确定的适用于不同方面的要求，并帮助识别模型中不一致或重叠的地方。

评估用例等级之后，就可以建立组织模型了

当使用案例模型是一个大项目的时候，它有利于从不同角度建立用例模型视图以及利益相关者，它是有益的使用要求的管理工具，允许过滤和分层模型不同。

步骤七、建立优先用例：

用例被要求表示驱动开发的过程，现代软件项目使用了一个迭代的过程——做到了早期项目减少风险的及推进其进展和更好的控制，优先用例的情况下，允许的建模过程之间的不同划分，着种方式将有助于迭代，并带动整体发展。

在该过程中存在着三种主要的风险：

1.业务风险：

主要涉及初始权重，“我们建立正确的产品？

是可行的吗？

”等等，关键的列表（概念）使用的情况下，由于风险水平的确定，对风险的评估也应该尽可能正式，再上一个例子中体现在新系统与老系统的提高的方面和可行性上。

2技术风险：

在技术上具有挑战性的问题应该具体处理和分析，例如上个例子中的实时定位系统的实施；

3.物流风险：

描述需要不应延迟交付进度，即一旦迭代和增量计划已经使用的情况下，如果第一个增值包括应急通信系统，并处理紧急呼叫，处理紧急援助请求，它将被分解为第一优先。

明显的优先级技术是通过水平处理使用的情况下，做一个完整的摘要等级的使用案例，然后发展到用户的目标水平。

描述第一这种方法对水平用户目标可以提供一个很好的问题概述（有助于降低业务风险），但接下来的风险水平（减轻建筑/技术风险），在有许多低水平的情况下，要承担技术风险，应可减轻早期的这种用例。

步骤八、描述用例：

到这一步，对每个用例的细节而言用例模型是相当薄的。

模型应该有一个确定的用例（每一个简短的描述和可能的前置和后置条件）；对于不同的使用情况下可能有一些初步的图描绘的使用，另外还要处理一些类别和优先关系。

文中提到的方法是用活动图描述用例，除

•大概操作过程——系统之间的相互作用以完成用例目标，在没有发生错误时要一步步操作；

•变化——不常见的交互路径（相对于主要的成功情景）；

•例外——交互系统时发生错误；

•假设——任何假设（系统不能保证条件）。

还要注意

•状态——使用情况的当前状态（初稿，验证，填充，完成等）；

•优先——使用的优先发展案例；

•利益相关者和关注——利益相关者（那些不一定是在用例中的角色）和他们的利益（在使用情况下必须受到保护）；

•问题 ——任何打开的问题方面的使用情况（开始这应该是空的，使用的情况下被宣告结束）；

•非功能行需求——这是相关的非功能性要求（性能，安全，安全等）；

•扩展点——步骤中使用的情况下延伸的使用情况不同（更多的“扩展”关系后）。

在面对有可能发生错误的地方还要着重注意

•捕捉点选择——误用的情况下能够预防或检测；

•最坏情况的威胁（而不是成功的保证）；

•检测保证——结果的一个预防的场景；

•预防保证——描述如果检测方案的结果。

步骤九、模型重构；

重构是改变一个模型的内部结构，使其变得容易理解和廉价，而不改变观察该模型的行为。

重构的第一种方法是基于行为的分布来重构，建议提取一个新的用例使用包含关系涉及到父母共同的行为。

有时普通的行为可以被认为是作为父母使用的两个案例（或更多）的使用情况，而重构，在这种情况下，类似是一个父用例创建和子的用例相关的场景。

在该例中，接一个紧急电话的同时，就要追踪收集到的事件的细节，打电话人员的信息和警察分布的区域，这些事件之间有追踪关系；

另一类重构是用例的变化因素，在主要的路径选择之间，什么时候一种替代路径可以影响的几个步骤，推荐在这些情况下移动替代路径中使用它自己的一个案例，在涉及两个用例的扩展关系的时候也可以使用扩展的关系。

在该例子中，人质位置的获得和自杀性炸弹的位置的获得都是利用位置获得工具，因此扩展出来的位置获得工具可以成为解决问题的工具，这样就使得问题大大简化并使图像和系统清晰明了。

合并使用的情况下，也可以在重构中删除用例相关的元素，在使用时发现在早期阶段确定的元素，不有助于系统的整体理解，甚至造成分散和误解。

此外，使用的情况下，似乎有意义的第一印象，可以留下未引用作为分析的进展。

C.配套支持措施

步骤十、验证和确认模型：

长期验证（“我们的产品好吗？

”）确定（“我们建立正确的产品”）是使用这么多的几乎都是相同答案的一个问题，然而，核查，验证和确认模型是非常重要的一步。

这里也有四个方法：

•检验（验证和确认）——一个人或一个团队已经开始有使用行为的情况下，根据预先定义的标准，以验证他们是否坚持标准和规范；

•评论（验证和确认）——涉及多个读者研究不同的用例的文物（文字，图表）。

评审应包括客户代表及其他利益相关者，组织团队的一步在小团队内部设立第二次审查与完整的组有利于在这里进行回顾；

•演练（验证）——一种形式的审查，积极提出一个用例或业务的情况（包括几个用例交互）可能扮演的角色，并验证以检查事件流。

•原型（验证）——这是基于快速原型向利益相关者（特别是客户）描述用例的行为。

这种方法的优点是可以通过用例捕获理解度，缺点是会增加的费用。

无论选择这些方法的哪个，重要的是要记住使用适当的验证以帮助减少上述问题的风险并且提高工程质量，这样会让顾客满意度提高。

步骤十一、添加未来的需求：

增加未来的需求不仅仅是需求管理方面的操作，而是针对那些在需求识别的特征分析，这是不打算开发但预计他们将作为未来需要的增强功能。

这些要求也被称为“规定“要求。

描述这样的要求是有益的，尤其是在已经确定这些未来的需求影响的整体架构的解决方案之后，以便解决这些需求，现在就着手会使集成更容易。

其中的方法叫做改变场景，在过程或目标将无法实现的情况下当前的系统要怎么改进才能使问题解决或者将变化的影响放在保持可追溯性信息来确定使用的情况下，这样会使设计更加合理并使影响朝着最积极的方向发展。

例如在该例中，仓库管理员在工作时要有两项功能来支持，即检查库存和填写订单，而当库存满了或订单不符合要时，就要有退回货物的操作，这是不可忽视的，在这一步中添加进来。

而全部预测未来是不可能的，我们只是模拟了最有可能发生的情况，即限制了一些因素的发展，来让用例模型完善化。

D.结束

步骤十二、决定何时结束：

它是制定退出或停止标准的建模，特别是考虑到使用的情况下，因为每个任务总是可以被分解为更小的，而对于较小的组分和几乎无限的任务。

决定什么时候停止是很微妙的，需要将不完整的需求与延迟项目风险平衡（或其运行成本增加不必要的）。

以下的问题可用于基本的停止准则

•所有角色和目标已覆盖？

•可以设计实现用例？

•在一个系统的情况下对各子系统的要求已在每个用例标识？

等等

决定什么时候停止是一个不可逆转的决定，如有需要，使用案例可以进一步详细的重新审视。

但是，对重新开放的用例模型而言，一旦它被关闭，可能是通过改变委员会批准，并确保有足够多的理由的步骤才能重启，因此应该谨慎和小心。

总结：

用例建模是捕捉系统要求的一个强大的技术，然而，像任何其他技术；它总会在应用中有一些挑战，这个用例建模经历了大量的重大挑战项目，它有独特的论证和详细的步骤来减轻一些风险，从而有助于双方项目可用团队，客户和其他利益相关者实现用例模型。

本文中所描述的方法只是交易周期之中用例模型，还有其他几个方面的开发生命周期可以对建模工作的成功起着一个显着的效果。

这可以在最重要的领域突出用例建模的影响：

•需求管理——管理要求的变化，防范对非托管的蠕变特性，增强对RFP的可追溯性等。

•配置管理——关于版本的使用案例。

这是重要的调节，对协调发展模式的团队工作起到重大作用。

•项目管理——设置优先权，设置正确的迭代次数，并管理工作的人员提供适当的工作，

•维护团队专注并推动项目管理——这意味着管理用例的开发团队，不让他们迷失在细节上，让他们了解早期的步骤描述

最后，在大型组织中的方法将需要因系统和实际情况而异，都应该各自匹配组织的文化和具体项目的需求。

但该文献中提出的大型复杂系统用例建模方法，相比市面上或多或少的各种思想，它的先进性和精密独到的见解一定会增加相似的大型系统或小型系统建模成功的几率，是可以也是值得被适当采纳的一种优良思想。