《收集系统需求》PPT课件.ppt

第十六章 收集系统需求,前面两章处理的是领域中的概念问题，产生了业务过程模型和类图。后面要进行的是研究实际的系统。任本章中，将学习：系统展望。联合应用开发会议(JAD session)。组织系统的需求。使用用例。,现在到了开发组开发未来餐馆的技术骨架的时候了。开发组现在已经得到了业务过程模型和系统的类图。下面就可以开始编码了吗?这种想法是错误的，他们甚至离编写程序还有一大段的距离。首先，他们必须要开发出个系统的视图。大部分项目都以“构造一个顾客信息数据库系统并使它具有对用户友好的界面，以便于可以花费最短的时间对用户培训”或者“构造一个尽量在最短时间内解决问题的基于计算机的辅助桌面软件”。而现在，开发组只能从一个不太明确的任务“使用技术建立未来的餐馆”开始。开发组必须事先设想出这个餐馆是,什么样了，这样才能估计出餐馆中的各类人员怎样在其中工作。他们现在处在一般的开发组所没遇到过的情况。开发组将使用他们所了解到的业务过程知识和新获取的领域知识，为的是看看外出就餐的哪些地方可以使用技术来改善。让我们来旁听一个开发组的会议。会议的成员有一名系统分析员、一名建模设计师、一名餐馆老板、一名服务员、一名厨师和一名系统工程师。另有一名主持会议的协调员。,16.1 开发系统的映像,协调员：“请看我们的业务过程模型图，我认为大家都看得出有好几处可以引进计算机技术加以改进。我在一块白板上做记录，哪位先发言?”协调员给每位与会者散发一份下图的拷贝。,分析员：“很明显，与大部分其他企业一样，餐馆的业务运做也要依赖信息的流动。如果我们能够加速信息的流动(这也是技术所擅长的)，就能够达到我们的目的。”餐馆老板：“我还不敢肯定已经理解了你的意思。你所说的“信息流动”指的是什么?我认为我的餐馆里一直在流动的是食物。”系统工程师：“我可以帮你说明什么是信息流动。当顾客下一份定单后，他就在给服务员传递信息，并且，当服务员将这个定单转交给厨师时，他就在使信息继续流动。”,协调员：“还有什么地方有信息流动?”服务员：“我想我已经有些明白了，当一名顾客叫我去问厨师定单完成情况时，也有信息流动，对不对?”分析员：“完全正确。”厨师：“但是服务员来问我饭菜做的如何时，我并不能真正做什么，一切还得照旧进行，在烹饪时我不希望被打扰。”协调员：“或许我们能找出一种使这种打扰降至最低程度的方法。对信息流动诸位还有什么看法?”,这时，协调员试图缓和厨师的情绪，以使他集中注意力开会。餐馆老板：“当服务员为顾客背诵每日特色菜点，或者回答顾客就菜单提出的问题时，这是不是信息流动?”协调员：“肯定也是。”厨师：“有时我也回答顾客提出的问题。顾客让服务员到厨房来问我某个菜做的怎么样时，我或者告诉服务员，由服务员转达给顾客，或者我不太忙时，会亲自出去解答顾客的问题。顾客喜欢我这么做。”,服务员：“我要告诉你我最不喜欢的一种信息流动。顾客下了一份定单，我将定单送到厨房，结果听到厨师说我们缺某个菜。这时我必须让顾客再点其他的菜。这通常会使顾客不高兴也让我不高兴，因为我的小费会受影响的。”分析员：“是不是应该把这个过程作为一个单独的业务过程另外讨论?”协调员：“也许。我认为各位会同意再为此单独开一个会。”协调员要尽量使与会者注意力集中到会议的主要议题上。注意协调员避免使用“是的，但”等,字眼。协调员：“让我们总结一下会议到目前为止的成果，根据我的记录，信息流动出现在以下几处：顾客下一份定单(点菜)。服务员将定单转交给厨师。顾客要求服务员到厨房探察定单的完成情况。服务员为顾客背诵每日特色菜点。服务员回答顾客就菜单提出的问题。厨师回答顾客关于某样菜烹饪方面的问题。与业务过程会谈时的情形一样，协调员在适当的时候暂停会议，做个总结将大有好处。,分析员：“我知道还有一处没有出现在业务过程模型图中。就是顾客如果对帐单有些疑问当服务员回答这些问题时，这也需要信息流动。”协调员：“对了，确实如此，业务过程中还有需要信息流动的地方吗?”系统工程师：“我发现了一处。在厨师与服务员之间进行协调时是不是也需要信息流动?他们不是要确保在顾客吃完小菜时给顾客同时上热的主菜吗？这时需要大量信息流动。”分析员：“我同意。这时的信息要以几种不同的方式流动。”,餐馆老板：“你只拿出了两幅业务过程模型图。我记得还有一幅。”协调员：“对了。还有一幅清理餐桌业务过程模型图。”,分析员：“看上去这幅图中只有一处信息流动的地方，但我敢打赌，这一处的信息流动十分重要：服务员召唤清洁师，通知清洁师立即清理餐桌。”餐馆老板：“是的，这是十分重要的。只有餐桌清理好了才能让新来的顾客就坐。清理餐桌必须进行的尽可能快，否则我们餐馆的休息室和候餐区里就坐满了又饿又气的顾客。”建模设计师：“在听到你们发言时，我同时在修改我的类图。我可以问个问题吗?让我们的系统具有评估招待顾客的工作效率的功能，这是不是个好主意?”,餐馆老板：“好主意。有了这项功能我们就知道是不是要改进我们的工作以及如何改进。你是怎么认为的？”建模设计师：“在我们的Customer类中设置两个属性arrivalTime和serveTime。我还准备再增加一个导出属性waitDuration它是serveTime和arrivalTime之差。对此你有什么看法?”餐馆老板：“好主意。这样我们就知道我们是怎样招待顾客的了。”分析员：“是的。还可以得到许多有用的数据例如每天所有顾客候餐的总时间每名服务员招待的,所有顾客的平均侯餐时间，等等。”建模设计师：“还有另一种可能。假设在Customer类中再增加一个叫做depatureTime的属性和一个导出属性mealDuration，它是depatureTime和serveTime之差，这样做如何?”协调员：“应该不错。还有其他好的想法吗?”建模设计师：“既然我们使用了基于时间的属性，不妨也为Server、Chef类中也添加一些这样的属性，用来告诉经理每个雇员的工作时间?”餐馆老板：“哦不，这种监视别人工作表现的做法不适合施加给员工我也不能这么做。并不是,他们工作偷懒(他们不会的)，仅仅是他们不愿意有一双眼睛始终盯着他们。如果能让每个人工作心情愉快，那么我们的餐馆就是一家好餐馆，顾客也能体会到。”厨师：“我同意。我前面讲过，做菜的时候不能被打扰，该需要多长时间就得需要多长时间。我不希望在我手里拿着一捆菜时，突然听到经理对我说必须在4分钟之内把这个菜做好。”服务员：“我也不想听到顾客在吃完主菜后说我迟迟才将甜点菜单拿来。”建模设计师：“好，我收回刚才的建议。既然你们刚才提了这么多合理的反对意见，我就应当删掉,Manager类中的“monitor(监视)”操作。同时，Customer类也做相应的修改。”,建模设计师的想法表明他总是不断地修改类图。建模设计师、餐馆老板和服务员之间的谈话说明了一个重要结论：让业务领域中的人也参与系统开发是绝对必要的。如果没有餐馆老板和服务员提供的反馈信息，开发组很可能就花费了不必要的时间和金钱去实施一些工作监视方面的需求特征，最后反而会自受其害。这样的想法一提出就遭到餐馆中的工作人员的反对，这样可以让开发组重新思考，并最终做出有利于餐馆工作人员的决定。协调员：“根据我所听到的，似乎我们可以将改进分为两方面，一方面是加速信息的传递速度，,另一方面是加快某项个人任务的完成速度。开发组的意见认为第二种不太受欢迎，而第一种却大有必要。我说的对不对?”(全体同意)分析员：“既然我们已经做了上述决定，下面是不是应该继续讨论系统具体的需求？”协调员：“当然。大家还有其他意见吗?”服务员：“为了传递这些倍息，我一晚上要来回走很多路。有的时候我还必须到离工作区很远的厨房去。携带东西和往返的路程非常花费时间，更别说还要穿着皮鞋来回走。”,分析员：“看样子我们的系统必须提供一些功能来消除，至少是减轻往返路程和携带物品。这样才能加快信息的流动。”协调员：“往返路程和携带物品？”分析员：“是的。我们的系统必须设法减少服务员的来回走动。很显然他们要到厨房去取回定单并把定单带回到餐桌旁，并且必须及时。”系统工程师：“我认为我们要决定某件事情。使用一个局域网来连接服务员和厨房以及服务员与清洁师如何?这样信息的流动速度就可以加快很多。”,分析员：“我不想过分地强调对系统的分析，但是局域网要在各个终端之间布线。这样的话，服务员虽然不用直接跑到厨房去，但也还得必须跑到终端面前。似乎有为了技术而使用技术的嫌疑，能带来什么好处呢?”系统工程师：“如果按照你说的方式来建立系统，那么我承认没带来什么好处。实际情况可能还会更糟糕。但是我的主意不是这样的。假设每名服务员和清洁师都携带一台终端一台手提式电脑。进一步假设找们在这些计算机之间建立一个无线网络。厨房和经理办公室里可以分别放一台桌面电脑终端。另一种可选的方案是让服务员和清洁师使用掌上,电脑。但手提式电脑一般带有显示器和键盘，这种特征可以为以后的设计增加灵活性。”分析员：“哦我喜欢你的这种方案。这样的系统可以解决不少问题。例如，当一组顾客决定了定单后，服务员可以将用户定单上的菜点输入到手提式个人计算机中，然后传到厨房的桌面电脑。这样可以省去服务员在服务区和厨房之间的往返。”服务员：“我喜欢这种方案。当顾客吃完小菜时，我就可以通过敲击我的手提式电脑上的键盘通知厨师顾客已经吃太小菜了，这样可以省去我亲自到厨房去告诉厨师准备上主菜。”,厨师：“这样我在厨房就可以获得服务员传来的信息。事实上，我所有的助手都可以同时收到消息，这可以通过把消息显示在几个大屏幕上做到。这样我可以有效地跟踪我的每个助手在做什么菜，并告知他们何时菜应该做好。让每个助手各负其责。”系统工程师：“当完成了定单上的菜点后，你可以通过厨房的桌面电脑向服务员的手提式电脑发送消息，告知服务员。服务员可以不必来回往返，校对某个菜是否已经做好。顺便提一句，我们可以将手提式电脑(handleld PC)简称为手提机。”服务员：“太好了。我也可以给清洁师发信号让,他过来清理餐桌，不用到处去找他们了。这样可以大大提高工作效率。”餐馆老板：“怎么具体实现这些呢?”系统工程师：“现在暂时可以不必关心这个问题。”协调员：“我们都同意这种方案了吧?我们的系统采用一个无线局域网，服务员和清洁师使用手提式个人计算机，经理办公室和厨房使用桌面电脑。现在只差一件事情了。”分析员：“差什么事情?”协调员：“为这个系统起个很酷的名字。”,分析员：不妨叫Wireless Interactive Network for Restaurant(餐馆无线交互式网络)?它的简写是WINNER，代表胜利者的意思。”协调员：“最后两个字有点多余。”系统工程师：“干脆就来个简洁明快的名字：Wireless Interactive NetworkWIN。”厨师：“我喜欢这个名字。”分析员：“我也是。WIN(胜利)这个名字无可挑剔。”协调员：“大家都同意采用WIN这个名字了吗?好，我认为我们的会议已经圆满成功。”,16.2 收集系统需求,既然开发组已经开发出实际系统的一个映像，是不是程序员就可以编码了，系统工程师可以开始部署系统了?绝对不是。开发组必须集中考虑用户的需求，而不能只以技术观点来开发系统。尽管会议中确定了某些方案，但是还必须将WIN系统中的概念提交给餐馆中的工作人员和经理，以从这些可能的用户那里获得反馈意见。GRAPPLE开发过程的下一个动作要做的就是这件事。在一个联合应用开发会议(JAD Session)中，开发组收集用户的需求，将需求编制成文档，有了,需求文档在手，就可以对项目耗费的时间和金钱做出估算。联合应用开发会议在一间正式的会议室举行，由一名协调员主持。将它称为“联合”会议是因为会议的成员不仅包括开发组成员，还要包括系统可能的最终用户和领域专家。参加这次会议的开发组成员有两名分析员，兼做会议记录员，还有一名建模设计师，两名程序员和一个系统工程师。可能的用户是三名服务员，两名厨师、两个餐馆老板和两名清洁师。这次会议的目标是产生能反映系统功能的包图，每个包代表系统的一个功能模块，其中包含了详细,说明该功能模块的若干个用例。,16.3 需求联合应用开发会议,协调员：“首先，感谢各位光临本次会议。这次会议的时间可能很长，但也会很有趣。我们要做的是收集一个被称为WIN的系统的需求。WIN系统中的基本模念很容易理解，它的大致情况是这样的：服务员使用手提式个人计算机与厨师和清洁师通信。清洁师也使用手提式计算机通信。厨房中安装一台桌面电脑和一个或多个显示屏幕。经理办公室中也安装一台桌面电脑。我所说的可以参见图上所示。,“我们希望将WIN系统安装在LNG餐馆中，并期望能够改进现有的业务，提高工作效率。为了,达到这一目标，需要各位告诉我们你需要系统为你做什么。换句话说，如果系统已经就位的话，那么你将怎样使用系统?这个问题在本次会议中将会反复被提出。会议结束时，我们将得到每个人都满意的一组系统需求。我们将使用它做为程序员构造实际系统所依据的系统蓝图的基础。我希望大家时刻记住：我们需要你们每个人对系统提出各种需求，不论你们的职位是什么。”分析员1：“我们能不能从系统的功能模块划分开始?”协调员：“理所当然。那么如何开始呢?”,餐馆老板2：“上一次讨论我没参加，但我认为这是一个好主意。我们可以按照餐馆中的空间区域组织系统的功能模块吗?大家知道，服务区需要一组功能，厨房需要另一组功能，候餐区也有一组功能，等等。”协调员：“这么做是一种可能性。”分析员2：“我看了业务过程图后，觉得它已经为我们提供了组织功能模块的方法了。”程序员1：“怎么组织?”分析员2：“按照角色。厨师必须做某些事情，服务员也必须做自己的一些事情，等等。”,协调员：“听起来很不错，大家同意这种组织方式吗？”(全体同意)协调员：“好！根据业务过程图和类图，人员角色有Server、Chef、Busser、Assistant和Manager。”餐馆老板2：“你是不是遗漏了两个?还应该有Coat-check clerk和Bartender吧?”协调员：“我将他们补充进角色列表，还将使用UML包图表示法跟踪需求。”(参见下图),建模设计师：“我赞成这样做。我会在类图中补充一些信息。CoatCheckClerk类早已经存在了。我将细化这个类并添加Bartender类。”,协调员：“现在已经有了功能包，应该从哪个功能包开始进一步分析?”服务员1：“从Server包开始如何?”,协调员：“好。你需要这个包中为你提供哪些功能?各位别忘了，尽管这个包所代表的角色可能与你的职位不一致，但还是请大家从各方面提出你的看法。每个人的建议我们都欢迎。”服务员2：“我希望能在我的电脑中输入定单信息，并将这些信息传递到厨房。”协调员：“好。还有别的吗?”服务员1：“我能跟踪定单的状态吗?”厨师2：“我能在定单完成后通知服务员吗?”协调员：“对，对。你们应该已经注意到了我,已经把你们要求的功能写到了椭圆形的图标里。这些图标被称为用例。我将重新请你们中的部分人讨论和分析这些用例，但这是下一次会议要做的事。”,16.4 结果,联合应用开发会议持续了好几天。当会议结束后，产生了一组需求，这些需求通过用例来表达，若干个相关用例被组织进一个包中。Server包中的用例有：,Chef包中的用例有：,Busser包中的用例有：,Assistant包中的用例有：,Bartender包中的用例有：,CoatCheckClerk包中的用例有：,下图是用UML表示法表示的这些包和用例，以及建模设计师增加了两个类和必要的关联后所得到的类图。,16.5 小结,在开发组的会议中，开发组开发了一个未来餐馆中信息系统的映像。开发组成员认为能否加快信息的流动速度是系统成败的关键，并且为此提出了一些技术方案。在一次联合应用开发会议中，开发组与系统可能的用户以及领域专家一同收集系统需求。需求收集的结果是一个包图，这个包图中的每个包代表了系统的一个主要功能模块。每个包中的用例详细说明这个包代表的功能。,开发组提交给客户的文档很多。包括业务过程图、类图和一组功能包。下面开发组就要编码了吗?还没有，他们还要分析功能包中包含的内容，这就是下一个动作的目标。联合应用开发会议的成员中有一部分可以是前期的开发组会议的成员，事实上这也是被推荐的。这部分成员可能会记住一些没在会议记录中记录下的关键细节。关于系统的功能模块划分，并不总是如本章所述的那样，按照角色来组织系统的功能模块。只是在餐馆这个特定领域按照角色组织功能模块比较,方便。其他类型的系统可能需要不同的功能划分。例如，一个帮助系统可能需要问题输入、问题解决和结果输出3个功能包，每个包中部包含若干个用例。,