基于的需求分析和解决方案设计精品文档Word格式.doc
《基于的需求分析和解决方案设计精品文档Word格式.doc》由会员分享，可在线阅读，更多相关《基于的需求分析和解决方案设计精品文档Word格式.doc（14页珍藏版）》请在冰点文库上搜索。
多媒体视频
\Powerpnt\
习题解答
\tPrep\answer
先修知识
在正式开始学习本章内容以前，学生须具备下列知识基础。
推荐补充
了解Windows程序设计的基础知识。
《基于VB.NET的Windows程序设计》
了解WEB类程序设计的知识。
《面向.NET的Web应用程序设计》
连接XMLWebService开发的知识。
《XMLWebService开发》
建议学时
课堂教学（2课时）
教学过程
序言
教学提示：
序言部分主要达到两个目的。
l明确为什么要学这本书？
学些什么？
学完以后可以做什么？
并激发学习动力。
（略讲）
l明确课程的结构，以及学习方法。
（精讲）
教学内容
教学方法
教学提示
讲授：
在下面的学习中，我们将开始学习关于.net需要分析设计的相关内容，也就是学习MSF的相关内容，了解软件开发的流程和软件需求设计的一些要点。
现在的许多同学可能都是各个方面技术的高手，可以独自搞定许多的技术难题，攻克许多技术难关。
但现在这个时代不再是个人英雄的时代了，而是一个强调团队精神的时代，我们需要的是一个强有力的开发运做团队，而不是个人。
而如何去使许多的高手能够组成一个成功的团队呢？
这就需要有一套完善的管理方法，管理团队成员适应不同的项目角色，同时管理项目的进度和进程及各个阶段应该做的事情和必须完成交付的成果。
本课程就介绍了一种满足这些要求的项目管理的方法，MSF的管理模式。
提问：
学生平时有没有接触MSF的经验？
l课堂提问用于帮助活跃课堂气氛。
但不宜拖得时间过长。
小结：
前面给大家介绍了本书的一些相关内容，想必大家对本书已经有了一个大致的了解。
本书分为11章节，围绕了MSF的流程进行展开，让大家能够清楚的了解如何基于MSF进行软件设计开发测试部署的一个总体流程。
本书的第一章对于什么是MSF做了一个整体的讲解，让大家在学习MSF之前对于MSF有一个整体的认识。
第二章讲解了在项目开始之初，如何对信息进行收集和筛选。
第三章就进入了MSF的构想阶段，第四章到第八章节，从各个方面说明了设计这个阶段所需要做的事情。
第九章单独一章节讲解了安全的需求。
第十章节及最后一个章节主要讲解了项目结束时所需要做的事情。
阅书：
浏览目录
l帮助学生建立全书的全局观。
学完后可以做什么
l激发学习兴趣和动力
在正式开始学习这本书以前，我们必须先掌握一些学习方法。
我们的课主要分为两种：
理论课和实验课。
理论课：
我们主要在教室里学习课本内容。
讨论课：
我们会把书上所学的东西到进行讨论，从中掌握相关的知识点。
我们手上有如下的一些材料
l课本
l学生光盘
n幻灯片（和上课演示的PPT是一样的）
n多媒体视频和交互练习
n实验文件（每次实验会用到一些文件）
n案例文档
n课外阅读
学习方法
l课前可以使用幻灯片结合书，做一些预习。
这样上课听起来会更轻松。
l认真完成好每章后面的习题和每次上机。
l自己在家里或寝室中做一些相关的试验。
光靠听讲是无法学会新知识的。
上机的时间也是不够的。
l和同学多交流学习的经验，借助他人的经验帮助自己成长。
演示：
学生光盘内容
l明确学生手头的资料
l建立正确的学习方法和观念
l关于学生光盘内容各部分作用参见本书教参相关部分
下面我们进入本章内容的学习，我们将分别对以下几个方面进行讨论：
nMicrosoft解决方案框架概述
nMSF过程模型的阶段
Microsoft解决方案框架概述部分主要达到两个目的。
l描述瀑布模型和螺旋模型。
l使学生认识MSF过程模型的各个阶段及组队模型中的角色。
教学活动
在上这门课之前，我想大家应该已经具备了开发Windows应用程序和Web应用程序的能力，也许部分同学还是某些技术方面的高手。
但单单只依靠这些技术我们是不是能很好的完成一个项目呢？
答案是肯定不行的。
这就好比一场战争的胜利，依靠两三个特种兵是搞不定的。
而要成功的完成一个项目，必须要有一个流程和项目的控制。
本章节就是讲解了用于设计和开发企业解决方案的一组模型、一系列原则和指导方针，从而保证能够成功地管理项目的所有元素，包括人员、过程及工具。
瀑布模型是由在1970年最初提出的软件开发模型，在瀑布模型中，开发被认为是按照需求分析，设计，实现，测试（确认），集成，和维护坚定地顺畅地进行。
瀑布模型是基于里程碑的，其实就好比我们从小学读到大学。
我们必须先读小学，当小学的知识我们已经合格后，才能读中学。
然后是大学。
只有当一个历程完成的时候才能进行下一个里程。
有些项目的需求和估计需要不断的完善，而螺旋模型正是基于这一需要出现的。
螺旋模型对于快速开发很小的项目比较有效。
因为客户在每个阶段都会提供反馈和认可，所以该方法可以在开发团队和客户之间建立非常紧密的配合。
但是由于在螺旋模型中没有引入明确的检查点，所以开发过程可能会变得相当混乱。
1.1.1
幻灯：
第10页
l简单的结合PPT的内容进行生活化的讲解。
大家认为成功的开发一个项目应该具备哪些过程？
l请学生开动脑子，自己先考虑项目应该经历哪几个过程。
l此问题用于帮助活跃课堂气氛。
MSF过程模型结合了瀑布模型和螺旋模型的最佳原则。
它将瀑布模型基于里程碑的计划和结果的可预测性，与螺旋模型的反馈和有创造力的优点有机的结合在一起。
1.1.2
第11页
l帮助学生建立MSF的概念。
l让学生产生技术以外项目管理方面的兴趣。
前面我们已经说到了MSF模型的几个步骤，那我们根据这几个步骤来看一下组织项目团队的方式。
一个项目组里会有很多的成员，分管了各个过程不同的工作内容。
在一个企业级解决方案项目中，必须完成很多的工作，而且还必须从几个不同的角度来观察这个项目。
为了满足这些需要，MSF组队模型指定了六个不同的角色，并且明确地定义了每个角色的责任和目标。
讲解Error!
Referencesourcenotfound.。
一个项目组里。
首先会有一个项目经理（PM），他将会负责和客户进行交流，收集客户需求信息等工作。
同时会有一个项目Leader（PL），他将会进行项目进度的管理和项目技术的攻关等操作。
他将带领了公司的项目开发人员（PG）和测试人员（PT）完成项目的开发和测试工作。
同时会有一个项目安装人员（PI）去把已经测试成功的项目在客户的实际环境中进行安装。
最后会有客户服务人员（CS）进行一直的跟踪客户使用体验，确认产品的实际使用效果。
各个项目成员是否可以彼此重叠角色呢？
讲解表1-2。
1.1.3
第12页
l讲解表格中的数据。
给学生一个基本概念。
三个关键的MSF准则是风险管理、就绪管理和项目管理。
当这些准则应用于MSF上下文的时候，MSF更倾向于强调如何对这些准则进行调整，而不是完全重建这些准则。
可以预计的是，其他附加的准则在将来也会进行调整。
我们来看一下这三大管理标准。
讲解课本：
1.1.4
为什么需要风险管理呢？
其实道理也很简单，我们在做任何事情的时候，父母都会教育我们朝好的方向去做，朝坏的方向去做准备。
我们在进行一个项目的时候，必须要考虑有可能出现什么紧急情况会使项目滞后，甚至是崩盘。
通过风险预测，我们可以为有可能出现的情况进行预防，或者去为有可能出现的紧急情况设计应对政策，这样，可以更好的保证项目能够按照我们预期的预算和进度进行开展。
同时，就绪管理和项目管理同样是为了达到更加好的管理项目的目的而存在的。
例如，假设你拥有一个电子商务网站，平均每小时可获得客户定单收入2000美元，则根据销售收入，网站的年度价值为17520000美元。
如果网站关闭6小时，则损失计为一年的0.000685%。
将这个百分比与资产的年度价值相乘，即可得到直接损失为12000美元。
在这个例子中，为了消除该事件所产生的负面影响，预计公司将花费10000美元做广告。
此外，估计公司的年销售额将减少0.1%，即17520美元。
将这额外支出的广告费和年度销售收入损失相加，即可得到间接损失共计27520美元。
当你知道自己的损失是多少的时候，你就可以制定你预防风险的策略，也同样可以优先制定出万一出现这样情况我们应该怎么办，比如关闭6小时是由于断电造成的，那我们就应该提前去买一个可以提供６小时电源的UPS装置。
第13页
项目评估和管理的过程中，需要一个贯穿公司战略、项目战略、项目具体计划三个层面的管理工具，本文试图通过对平衡记分卡这一管理工具的创新，在结合项目管理的特点之后创制项目平衡记分矩阵这一工具分析项目和公司战略，项目战略管理，项目计划三个层面的权重关系，生成项目计划。
1.1.5
其实这个观点体现在企业实际项目中也非常好理解，说白了，就是用有限的钱做更多的事情。
本文这里介绍到的内容就在于讨论如何分配企业的资源在企业最需要的地方使用。
同时又可以顾及到企业其他的部门的进度不受到限制。
比如当企业接到一个订单，经过预算，此项目的保本额度是５人月，而客户报价给我们的是８个人月，也就是说这个项目可以如果使用５个人做一个月的话，那我们可以赚到３个人月的利润。
而如果用５个人做２个月才完工的话，那等于说我们要亏掉２个人月的钱。
这种情况下，我们就要衡量公司的资源制定住项目的人员安排了，如果此时公司正处于项目资源比较少的时间段，人手比较多的话，那我们可以使用２个人，就算做上２个月，那也只有４个人月的总量，既可以把项目做的很稳，又可以节约人月开销；
但是如果此时公司处于项目紧张阶段，后面一个月马上会有几个新的项目接的来，这个项目，我们必须在本月完成，那有可能我们会配备６个人做一个月，甚至在不到一个月内完成该项目，以达到将人力成本不浪费在一个项目的目的，但付出的代价就是本项目可能会少赚一点。
这就是一种平衡资源的方式。
但绝对不止这一种，很多情况下还要根据项目和客户的具体要求进行项目的配置。
第16页
随着解决方案的开发不断地深入到各个阶段，开发过程的每次迭代都会使解决方案更接近于它的最终发布版本。
而在一个具体的过程中迭代则会不断的进行，直到实现该阶段的目标。
另外，迭代允许项目以更详细的步骤进行开发，从而使未来的迭代过程可以根据早期步骤的成功或失败来进行。
远景/范围文档和其他的文档、代码、设计和计划等交付成果都是以迭代的方式开发的。
我们这其中会涉及到的迭代的例子包括版本发布，即时文档，定期创建内部版本。
比如国内的一家移动软件提供商俊晗工作室开发的基于WindowsMobile2003的迷你万年历软件，最一开始该软件只具备一些简单的日历功能，然后通过对市场反馈的研究和对用户使用体验的分析，发觉客户有一些进一步的需求，比如：
希望能够提供医学上的生物律的功能，预测自己每天心情，体力，智力的走势。
就这一新的要求，该公司进一步提出新的方案和远景规划，进一步加强软件的功能，加入了PSI生物律预测模块，满足了客户的要求。
同样的循环还在进行中。
经过一年多的修缮和补充，目前该软件已经可以具备除日期显示以外的许多其他辅助加强功能，例如：
提供和机器的通讯录同步，然后标注一些重要人员的生日或重要日期的提醒功能。
提供了根据太阳的位置指示南北的指南针功能，提供了供娱乐使用的周公解梦的功能等等。
大大满足了用户对于移动软件的需求特点。
这其中将会出现各种远景设计文档和计划分析文档。
1.1.6
第17页
本节主要达到一个目的。
l描述MSF过程模型的构思、计划、开发、稳定和部署这五个阶段的任务、里程碑和交付成果。
构思的目标是：
创建一个关于项目的目标、限定条件和解决方案的概要视图。
构思的目的是在项目的目标和限定的条件上能较早地达成共识。
而其实构思是一个项目成功的基础，因为它建立了一个大家都能接受的基准，团队成员正是在这个基准之上构建解决方案的。
例如：
1、干系人参与的重要性
项目干系人的参与是十分重要的。
首先需要将项目的干系人划分各个级别，如：
项目发起人、项目业务需求人员、项目数据人员、项目最终使用人员等；
将干系人分类，主要是为了可以确认项目在实际应用中人员的水平如何，以应用在项目的设计过程中，明确要细化的程度。
其次干系人确认之后，根据所属的种类不同，要求干系人负起项目相应的责任与决策，以便可以设置相应的控制点监控项目的状况。
定期向项目干系人发送项目的进度报告，说明项目的进展情况，及时了解干系人对项目的满意程度，从而调整项目的进展，以满足需求方的要求。
只有得到项目方的评估确认之后，项目方可进入下一阶段。
第三项目干系人的参与可以增强干系人对项目的支持与合作程度，方便项目的后续发展。
邀请项目干系人成为项目的总设计师或推广人，是为了让公司的领导者，可以经常与项目开发团队交流，描述事先解决方案是否可行，为项目提供预见的解决方案并支持这个解决方案；
而且还可以作为解决方案的忠实的支持者，减少企业其他部门对项目的开展可能引发的变化的抵触情绪。
2、MSF构思阶段的目标、里程碑和交付成果
MSF的构思目标指：
创建一个关于项目的目标、限定条件和解决方案的概要图。
而构思阶段的里程碑和交付成果：
就是远景/范围文档、项目结构文档、初始风险评估文档。
除了确认项目干系人结构外，还需要建立项目的远景/范围文档。
建立远景文档的主要目的就是在明确的最终目标是什么，会给项目参与人员及项目使用人员最终带来何种的益处；
以及该项目主的实现的功能范围是哪些内容，应用于哪些领域内。
项目结构文档定义了团队在组织和管理项目时所采用的方法。
对项目团队成员来说是一个很好的参考文档，可以帮助团队成员有效地协同工作。
例：
团队角色清单和相关的责任清单，团队成员的联系方式等。
初始风险评估文档，可以从项目技术风险、资金风险、实施风险、维护风险等各方面列举项目正式开始之后可能存在的风险问题，并将各种风险形成列表的方式，说明各种风险存在的引发条件、发生的机率、相应的解决方案以及相应的风险控制人员，即将风险问题形成列表，交给相应的风险负责人监控，并不断的调整风险列表，以适应项目的进展情况。
例如移动软件提供商俊晗工作室在开发基于WindowsMobile2003的迷你万年历软件之前，首先必须明确开发该项目应该使用的人员的多少及技术水平的能力。
同时必须设计出一个大概的的原型，即该软件中应该包括哪些基本的功能，能够完成哪些基本的动作。
然后还必须预测市场对于此软件的反响可能如何。
销售量可能是多少，针对这个预测销售量，可以大概估计该项目立项的风险是多少。
这些都将是在项目开始前需要做的事情。
只有通过设计和预测，才能大概看出该项目的可行性大小。
只有当公司的决策层认为该项目具备可行性，那么项目才可以立项进行开发。
1.2.1
第21页
在规划阶段，项目组要制定详细的解决方案，解决要建设什么，如何建设，谁来建设以及何时完成建设等问题。
在这一阶段中，项目组一直工作在设计过程中，创建起解决方案的体系结构和设计方案，编写功能说明，为各种可交付成果准备工作计划、成本估算和时刻表等。
规划阶段的最终点是项目规划批准里程碑，这个里程碑标志着项目组、客户和项目关键参与者已经对方案的详情达成了一致。
由小组成员为通信、测试和安全等领域制定的各种方案通过项目经理的协调整合到一个总方案中。
项目组在该阶段中的目标就是编制解决方案的文件，直到项目组可以及时经济地生成并部署该解决方案。
这些文件被看成是活跃文件，意思是说在整个规划阶段中都要对其不断进行更新。
在规划阶段要付出辛勤的劳动，方案和进度往往要反复几次才能定型。
不过，这样可以减少风险并提高成功的机会。
项目组在该阶段中要不断地发现风险并解决新出现的风险。
概念性设计
概念性设计描述了为解决方案的每个主要功能所提供的功能。
对移植项目来说，概念性设计从大体上来说与为现有应用或基础设施组件版本建立的设计相同。
尽管如此，在功能说明中为移植项目明确地说明这一计划还是非常重要的，当前组件的实际构思可能已经与其最初设想有所不同了。
即使概念性设计一直没变，它仍然可以成为后续阶段的试金石。
例如，在概念性设计中就对解决方案中必需包括的每个用户接口单元做了说明。
概念性设计解决了解决方案如何同时为用户和管理员工作的问题。
项目组在设计时要考虑到所有用户配置文件组的需求。
为此，他们首先必需要对需求获得深入的理解。
这项工作是通过复审在构想阶段编制的一系列文件完成的：
业务需求
用户需求
使用方案
运行要求
系统需求
设计者把这些需求作为描述性内容汇集起来，成为功能说明的一部分。
逻辑设计
逻辑设计需要用到概念性设计的每一个细节，并将其分配到体系结构中的特定逻辑角色上。
对基础设施项目来说，这种体系结构可能是一系列的框图，给出了网络、服务组件和网络连接要素等细节。
应用体系机构通常最少被分解为三个层面：
表示层、业务层和数据层。
由于是一个移植项目，项目组应当为现有的逻辑设计以及被移植应用或基础设施组件的逻辑设计进行备案，突出变更的区域。
可能有必要对项目范围外的其他组件如何与移植主体互动进行阐述。
结构设计
解决方案的结构设计指定了应当将哪些逻辑部分匹配到体系结构的特定物理部分上去。
结构设计应当包括达到性能目标、运行时间目标的预定度量标准和将要编写的解决方案代码里程碑。
例如，结构设计可能需要在部署之前将处理速度性能需求包括进来，还必需建立起针对特别部署方案的生产尺度。
移植部署方案需要描述完全移植的技术在移植完成后如何存在，不过还需提供比这更多的信息。
它们还必需要涉及到如何用新的应用或基础设施在不影响目前服务水准协议（SLA）的前提下取代现有的应用或基础设施。
换句话说，部署方案必需要同时给出最终的理想状态，还要从部署工作的角度给出从当前组织状态达到该理想状态的路径。
在这个阶段，俊晗工作室的设计人员通过预计要开发的大概原形，设计出该软件的细致的模块划分及开发手册和项目规约等东西，同时制定出项目人员的开发进度。
讲解课本1.2.2。
1.2.2
第22页
开发阶段的主要目标是要建立解决方案组件代码以及文档。
不过，某些开发工作可能会延续到稳定阶段以对测试作出响应。
开发阶段的内容不仅仅是代码开发和软件开发商。
基础设施也是在这一阶段开发的，所有角色都在创建和测试交付内容。
在开发阶段，俊晗工作室的技术总监会根据设计的式样书，根据项目进度，带领开发团队进行项目的开发测试等工作，并在完成测试之后，提供测试报告。
1.2.3
第23页
稳定阶段的首要目标在于提高解决方案质量，满足验收标准，进而交付生产。
在这一阶段中，项目组要完成任务并开发出可交付使用的产品，使功能齐全的构造过渡到质量达标状态，而且解决方案可以面向全面的生产部署。
本阶段的测试对以前开发过程中进行的测试做出了补充，其方法就是以实际环境为条件强调使用和运行。
项目组的工作重心要放在解决和筛选（按优先次序处理）错误以及对解决方案进行发布前的准备上。
在本阶段的初期，通常要进行测试以报告错误，其速度要比开发人员处理错误的速度快。
我们无法判断会有多少个错误或者要花费多长时间来解决这些问题。
但是，有两个被称为错误集中和零错误反弹的统计标志可以协助项目组估计出解决方案达到稳定状态所需的时间。
当项目开发测试完成之后，公司会首先通过一些代理商和平台商将该软件的ＢＥＴＡ版本问世，提供给一些收到公司邀请的测试用户进行使用。
通过测试用户的使用，可以反应出该产品的一些问题，例如功能的不完善，操作不够人性等。
这样，就有利于在公司发布正式版本之前进一步的修缮该软件。
1.2.4
第24页
部署阶段的最终目标是要将解决方案放到生产环境中去。
配合目标包括展开解决方案技术和组件、使部署稳定以及将项目迁移到运营和支持部门。
部署完成之后，项目组要进行一次项目复查和客户满意度调查。
在这期间可能会一直进行稳定活动。
部署阶段在部署完成里程碑处达到最高峰，此时项目组将获得客户对项目的最后核准。
部属阶段就是最后的发布了，在该软件发布后，公司同时还提供了客户服务，客户咨询等事务。
为公司进一步能获得该产品的修改，添加功能等提供计划和前提。
1.2.5
第25页
总结
经过本章的学习，我们了解了下列的知识和内容。
在第二章中，我们将进行收集和分析信息的学习，让大家能理解收集和分析信息在ＭＳＦ中起到什么作用。
布置作业
完成书后习题1-8
案例教学
对应本书光盘“CASESTDY\第一章\阅读文档\”,主要介绍本章案例的一些背景，为后期章节进行讲述提供场景背景。
13
升级会员 