试题二 论用例的获取方法 2004年上
UP （Unified Process, 统一开发过程）是一种软件开始过程，它的突出特点是：用例驱动；以构架为中心；迭代和增量式开发。用例（use case）是对一组动作序列的描述，系统通过执行该动作序列，为参与者（actors ）产生可观察的结果。用例不公可以描述系统的需求，而且能驱动系统的设计、实现和测试。
请围绕" 用例的获取方法" 论题，依次从以下三个方面 进行论述。
1．概要叙述你参与分析和开发的软件项目以及你所担任的主要工作。
2．详细论述你在这个项目中获取系统的用例的基本步骤。
3．分析并讨论获取用例的效果（是否获取了系统的所有用例或全部重要的用例）并进行评价。
摘要
项目及工作
基本步骤，识别参与者、识别用例、编写用例规约、识别用例的关系、用例分包和排序 效果分析
[摘要]
2007年5月XX 珠宝加工厂启动了“首饰生产加工管理系统”的建设，系统提出建设的主要目的是解决目前纯手工方式进行记账而造成账目混乱、信息流通不畅等问题，系统包括基础资料管理、仓库管理、生产管理、仓库查询、生产查询、权限管理等六个子系统。我承担了项目管理、需求分析、系统设计等多项工作。
在需求分析阶段，我采用用例模型来对系统的需求进行规格化说明。采用识别参与者、识别用例、编写用例文档、识别用例的关系、用例分组和排序等步骤来获取用例。这些步骤不是一次完成的，后面的步骤会导致前面步骤的调整，因此是一个迭代的过程。用例来源于客户，因此在用例获取过程我们注重与客户的有效沟通。
由于用例模型有效的描述了用户需求，用户也易于理解、评审用例，因此在需求分析后续阶段，没有发现重大需求误解或遗漏，有效保证了项目进度和质量。系统于2008年2月正式上线，比客户要求的时间提前了一个月，客户感到很满意。
[正文]
XX 珠宝加工厂是福建省最大的珠宝加工厂，主要生产真钻首饰、锆石首饰与素金首饰。其中真钻首饰比较贵重，一般都是一个款式生产一件，日均生产首饰100多件。每个首饰加工过程要经过数十道工序加工，在加工收发过程需要记账，记录原料使用、原料损耗、工人费用等情况。目前这些记账工作由10多个“交收人员”手工记账。XX 珠宝加工厂面临的问题是：原料使用、工人工费等账目都采用手工方式在纸上记录，账目混乱且不易查询统计，工序单采用纯人工方式进行跟踪，效率低下。
为了解决上述的问题，于2007年5月启动了“首饰生产加工管理系统”。系统实现基础资料管理、仓库管理、生产管理、仓库查询、生产查询、权限管理等六个子系统。其中仓库管理和生产管理是日常业务运行最常使用的子系统。仓库管理主要包括：仓库信息管理、采购入库、库存转移、库存调整、库存盘点、销售出库等功能。生产管理主要包括：开工序单、工序单收发、工序当转移、生产物料收发、生产入库、生产出货等功能。系统采用C/A/S和B/A/S两种三层体系架构结合的方式，开发工具采用VS.NET2003，数据库采用SQL SERVER2005。
在项目建设过程中，本人承担了项目管理、需求分析、系统设计等多项工作。在需求分析阶段，考虑到目前面向对象方法和UML 已经占据主流地位、面向对象需求捕获的主要模型“用例模型”描述的需求易于用户和设计人员理解等原因，因此我们采取了用例来捕获用户需求。下面介绍在该项目中我们获取用例的基本步骤。
1、 识别参与者
参与者是在系统之外，通过系统进行有意义交互的任何事物。我们通过提出一系列的问题来识别参与者。谁是系统的主要使用者？谁改变系统的数据？谁从系统获取信息？谁维护、管理系统以保证系统的正常运行？谁需要系统支持其日常工作处理？系统与哪些外部系统进行交互？通过对工厂组织结构和业务过程的了解，根据我们的经验以及对以上问题答案的寻找，我们确定了系统的参与者。系统的参与者包括开单员、销售人员、交收、仓库管理员、经理、财务人员、系统管理员等参与者，仓库管理员又分金仓管理员、钻石仓管理员、锆石仓管理员、成品仓管理员等参与者。交收又分银版交收、倒模交收、修摸交收、配石交收、镶嵌交收、蜡镶交收、微镶交收、电金交收、成品交收等。
2、 识别用例
用例是参与者通过系统达到某个有意义的目标，用例用于描述用户的功能需求。我们通过头脑风暴和参与者代表访谈两种方式来识别用例。我们主要通过几个问题的思考和询问来发现系统的用例。参与者希望系统执行什么任务？参与者在系统中访问那些信息？参与者需要把外界的哪些信息提供给系统？通过以上方法我们识别出系统用例，例如，我们识别了参与者“仓库管理员”执行的用例有登录系统、修改密码、采购入库、转移库存、调整库存、盘点库存、销售出库、查询库存结余、查询库存变动等。
3、 编写用例文档
用例文档是对一个用例进行详细说明，包括用例名、执行者、前置条件、后置条件、基本路径、扩展路径、字段列表、业务规则等内容。编写用例文档是用例获取过程工作量最
大的步骤，其中基本路径和扩展路径是要编写的主要内容。基本路径是指系统正常、成功执行的路径，扩展路径是指系统要处理的异常或分支。用例文档的内容来源于对参与者代表的访谈和分析人员的经验，我们针对逐个用例，询问参与者代表并进行思考的问题包括：参与者输入或记录哪些信息？系统要做何处理？系统需要显示何种信息？会出现何种异常情况？在实际面谈过程中，对于异常情况的分析帮助我发现了一些遗漏的用例。例如在调研收回工序单用例时（首饰经过一道工序的加工，从工人手上收回到交收手上），交收代表说明可能出现的异常情况有：首饰因为加工不当损坏了，首饰上镶嵌的钻石破了。从而我们发现了作废工序单、拆石熔金（从损坏的首饰中分解出各种原料）、登记破石、登记失石等用例。
4、 识别用例之间的关系
识别用例之间的关系是分析人员对已识别的用例进行系统思考过程的产物，用例的关系包括包含、扩展、继承三种关系。扩展用于分离扩展路径。包含用于提取公共的步骤，便于复用。继承用于表示同一业务目的的不同实现。我主要应用了包含和扩展关系，例如采购入库用例包含了查看供应商用例。
5、 用例分组和排序
我采用分主题的方式对用例进行分组，把用例分为基础资料、仓库管理、生产管理、仓库查询、生产查询、权限管理等六个包，便于用例的组织和管理。我对用例进行优先排序，按用例的优先级来安排用例的实现。进行优先级排序主要考虑的策略是：系统的核心流程优先，技术上有难度、有风险的用例优先。生产管理包中的用例是系统的核心流程，同时由于采用条码、ID 卡确认等技术，这些技术在之前的项目开发中没有涉及，技术上有一定风险，因此我们把它们的优先级排在最高，优先安排实现。
需要说明的是，上述的步骤并非一次性完成的，在每一个步骤中都可能导致对以前步骤的调整。例如前面讲到的例子，我们在编写用例文档步骤，又识别出新的用例，导致识别用例步骤的调整。需要强调的是，用例获取过程要注重与用户的沟通，在识别参与者、识别用例、编写用例文档都离不开与客户的沟通。因为用例用于描述功能需求，而功能需求来源于客户，所以成功的获取用例离不开有效的客户沟通。而完成一个用例文档的编写后，需要给用户进行评审、确认，来保证用例的正确性。
由于我们采用了有效用例获取技术、合理的用例获取步骤，在需求分析阶段，基本获取了所有主要的功能需求。用例从用户的视觉出发描述用户与系统的交互过程，用户能够看懂用例，因此在需求评审阶段能够及早发现需求的问题，并由分析人员进行改正。在后续阶段，没有因为需求误解造成返工，也没有因为突然发现一个重要的需求需要实现而造成进度
拖延，从而保证了项目的进度和质量。系统在2008年2月份正式上线运行，比用户要求的时间提早了一个月。系统上线后，运行稳定，有效支持客户日常业务处理过程，满足了客户方领导在项目建设初期提出的管好金原料、钻石原料、工人计件工资、生产过程的目标。客户感到很满意，这也有效的保证了项目能够百分百回款，因此公司领导也很高兴，对项目组成员进行了嘉奖。
试题二 论用例的获取方法 2004年上
UP （Unified Process, 统一开发过程）是一种软件开始过程，它的突出特点是：用例驱动；以构架为中心；迭代和增量式开发。用例（use case）是对一组动作序列的描述，系统通过执行该动作序列，为参与者（actors ）产生可观察的结果。用例不公可以描述系统的需求，而且能驱动系统的设计、实现和测试。
请围绕" 用例的获取方法" 论题，依次从以下三个方面 进行论述。
1．概要叙述你参与分析和开发的软件项目以及你所担任的主要工作。
2．详细论述你在这个项目中获取系统的用例的基本步骤。
3．分析并讨论获取用例的效果（是否获取了系统的所有用例或全部重要的用例）并进行评价。
摘要
项目及工作
基本步骤，识别参与者、识别用例、编写用例规约、识别用例的关系、用例分包和排序 效果分析
[摘要]
2007年5月XX 珠宝加工厂启动了“首饰生产加工管理系统”的建设，系统提出建设的主要目的是解决目前纯手工方式进行记账而造成账目混乱、信息流通不畅等问题，系统包括基础资料管理、仓库管理、生产管理、仓库查询、生产查询、权限管理等六个子系统。我承担了项目管理、需求分析、系统设计等多项工作。
在需求分析阶段，我采用用例模型来对系统的需求进行规格化说明。采用识别参与者、识别用例、编写用例文档、识别用例的关系、用例分组和排序等步骤来获取用例。这些步骤不是一次完成的，后面的步骤会导致前面步骤的调整，因此是一个迭代的过程。用例来源于客户，因此在用例获取过程我们注重与客户的有效沟通。
由于用例模型有效的描述了用户需求，用户也易于理解、评审用例，因此在需求分析后续阶段，没有发现重大需求误解或遗漏，有效保证了项目进度和质量。系统于2008年2月正式上线，比客户要求的时间提前了一个月，客户感到很满意。
[正文]
XX 珠宝加工厂是福建省最大的珠宝加工厂，主要生产真钻首饰、锆石首饰与素金首饰。其中真钻首饰比较贵重，一般都是一个款式生产一件，日均生产首饰100多件。每个首饰加工过程要经过数十道工序加工，在加工收发过程需要记账，记录原料使用、原料损耗、工人费用等情况。目前这些记账工作由10多个“交收人员”手工记账。XX 珠宝加工厂面临的问题是：原料使用、工人工费等账目都采用手工方式在纸上记录，账目混乱且不易查询统计，工序单采用纯人工方式进行跟踪，效率低下。
为了解决上述的问题，于2007年5月启动了“首饰生产加工管理系统”。系统实现基础资料管理、仓库管理、生产管理、仓库查询、生产查询、权限管理等六个子系统。其中仓库管理和生产管理是日常业务运行最常使用的子系统。仓库管理主要包括：仓库信息管理、采购入库、库存转移、库存调整、库存盘点、销售出库等功能。生产管理主要包括：开工序单、工序单收发、工序当转移、生产物料收发、生产入库、生产出货等功能。系统采用C/A/S和B/A/S两种三层体系架构结合的方式，开发工具采用VS.NET2003，数据库采用SQL SERVER2005。
在项目建设过程中，本人承担了项目管理、需求分析、系统设计等多项工作。在需求分析阶段，考虑到目前面向对象方法和UML 已经占据主流地位、面向对象需求捕获的主要模型“用例模型”描述的需求易于用户和设计人员理解等原因，因此我们采取了用例来捕获用户需求。下面介绍在该项目中我们获取用例的基本步骤。
1、 识别参与者
参与者是在系统之外，通过系统进行有意义交互的任何事物。我们通过提出一系列的问题来识别参与者。谁是系统的主要使用者？谁改变系统的数据？谁从系统获取信息？谁维护、管理系统以保证系统的正常运行？谁需要系统支持其日常工作处理？系统与哪些外部系统进行交互？通过对工厂组织结构和业务过程的了解，根据我们的经验以及对以上问题答案的寻找，我们确定了系统的参与者。系统的参与者包括开单员、销售人员、交收、仓库管理员、经理、财务人员、系统管理员等参与者，仓库管理员又分金仓管理员、钻石仓管理员、锆石仓管理员、成品仓管理员等参与者。交收又分银版交收、倒模交收、修摸交收、配石交收、镶嵌交收、蜡镶交收、微镶交收、电金交收、成品交收等。
2、 识别用例
用例是参与者通过系统达到某个有意义的目标，用例用于描述用户的功能需求。我们通过头脑风暴和参与者代表访谈两种方式来识别用例。我们主要通过几个问题的思考和询问来发现系统的用例。参与者希望系统执行什么任务？参与者在系统中访问那些信息？参与者需要把外界的哪些信息提供给系统？通过以上方法我们识别出系统用例，例如，我们识别了参与者“仓库管理员”执行的用例有登录系统、修改密码、采购入库、转移库存、调整库存、盘点库存、销售出库、查询库存结余、查询库存变动等。
3、 编写用例文档
用例文档是对一个用例进行详细说明，包括用例名、执行者、前置条件、后置条件、基本路径、扩展路径、字段列表、业务规则等内容。编写用例文档是用例获取过程工作量最
大的步骤，其中基本路径和扩展路径是要编写的主要内容。基本路径是指系统正常、成功执行的路径，扩展路径是指系统要处理的异常或分支。用例文档的内容来源于对参与者代表的访谈和分析人员的经验，我们针对逐个用例，询问参与者代表并进行思考的问题包括：参与者输入或记录哪些信息？系统要做何处理？系统需要显示何种信息？会出现何种异常情况？在实际面谈过程中，对于异常情况的分析帮助我发现了一些遗漏的用例。例如在调研收回工序单用例时（首饰经过一道工序的加工，从工人手上收回到交收手上），交收代表说明可能出现的异常情况有：首饰因为加工不当损坏了，首饰上镶嵌的钻石破了。从而我们发现了作废工序单、拆石熔金（从损坏的首饰中分解出各种原料）、登记破石、登记失石等用例。
4、 识别用例之间的关系
识别用例之间的关系是分析人员对已识别的用例进行系统思考过程的产物，用例的关系包括包含、扩展、继承三种关系。扩展用于分离扩展路径。包含用于提取公共的步骤，便于复用。继承用于表示同一业务目的的不同实现。我主要应用了包含和扩展关系，例如采购入库用例包含了查看供应商用例。
5、 用例分组和排序
我采用分主题的方式对用例进行分组，把用例分为基础资料、仓库管理、生产管理、仓库查询、生产查询、权限管理等六个包，便于用例的组织和管理。我对用例进行优先排序，按用例的优先级来安排用例的实现。进行优先级排序主要考虑的策略是：系统的核心流程优先，技术上有难度、有风险的用例优先。生产管理包中的用例是系统的核心流程，同时由于采用条码、ID 卡确认等技术，这些技术在之前的项目开发中没有涉及，技术上有一定风险，因此我们把它们的优先级排在最高，优先安排实现。
需要说明的是，上述的步骤并非一次性完成的，在每一个步骤中都可能导致对以前步骤的调整。例如前面讲到的例子，我们在编写用例文档步骤，又识别出新的用例，导致识别用例步骤的调整。需要强调的是，用例获取过程要注重与用户的沟通，在识别参与者、识别用例、编写用例文档都离不开与客户的沟通。因为用例用于描述功能需求，而功能需求来源于客户，所以成功的获取用例离不开有效的客户沟通。而完成一个用例文档的编写后，需要给用户进行评审、确认，来保证用例的正确性。
由于我们采用了有效用例获取技术、合理的用例获取步骤，在需求分析阶段，基本获取了所有主要的功能需求。用例从用户的视觉出发描述用户与系统的交互过程，用户能够看懂用例，因此在需求评审阶段能够及早发现需求的问题，并由分析人员进行改正。在后续阶段，没有因为需求误解造成返工，也没有因为突然发现一个重要的需求需要实现而造成进度
拖延，从而保证了项目的进度和质量。系统在2008年2月份正式上线运行，比用户要求的时间提早了一个月。系统上线后，运行稳定，有效支持客户日常业务处理过程，满足了客户方领导在项目建设初期提出的管好金原料、钻石原料、工人计件工资、生产过程的目标。客户感到很满意，这也有效的保证了项目能够百分百回款，因此公司领导也很高兴，对项目组成员进行了嘉奖。