记录督促学历历程2

第三章

7.25
由于，限制于篇幅以及编辑繁琐程度，本来准备用图片形势呈现思维导图的方式进行要点梳理和补充，所以退而求其次，重点内容自我归纳文字形式进行整理，

第三章主要是，需要理解敏捷软件的定义以及开发的基本原理、敏捷方法的内涵，还有敏捷方法和计划驱动软件开发方法之间的一些差异，第二就是了解极限编程的定义，以及极限编程的主要做法，最重要的是知道极限编程是怎么要遵循敏捷软件开发的原理，第三是了解，大型软件系统在其进行开发过程中是如何采用敏捷方法的，问题的关键，我认为在于理解什么事敏捷软件开发，对此我查阅了相关资料：Agile software development 是 敏捷软件开发的英文名字，是一种能够应对快速变化需求的软件开发能力，敏捷软件开发相较于其他软件开发的主要区别在于能够尽快的促使程序员团队和业务人员进行信息交流，以及频繁及时的更迭软件版本，能够很好的适应需求的变化的一种组织方法，我是这么理解的，另外，敏捷软件开发更加强调各个部门的人员在各司其职的基础上进行更多的沟通，相较于其他的开发方式，其更多能发挥个人对于项目的作用，在我看这一章导言部分的时候，我发现自己对于上一章节描述的 需求描述有所混乱，我需要在看完此书之后再次进行阅读，同时，手写笔记思维导图也是必须要做的，如有需要我会在之后更新在我写这些东西的后面。

本章前半部分主要论述了，关于快速软件开发的一些基本特性，因为虽然对于软件开发有很多不一样的方法，但是呢，其中都有一些共性，例如：1描述和设计以及实现过程是交织在一起的，其中最重要的是最后一句，用户需求文档定义为最为重要的系统特性。2系统是通过一系列版本开发出来的，这使我想到最开始一章所讲不同软件系统差异那一部分所讲的一个系统类别，需要不通迭代，3，系统用户界面通常是采用交互式开发系统开发的，这一个特性我不是特别明白，需要做一个重点标记。

敏捷方法是增量式开发方法，每个增量一般都比较小，通常，每两三个心气就会创建系统的新版本并提供给拥护使用。用户参与开发过程，以便快速地获取变更需求的反馈，利用非正式的沟通，而不是采用有书面文件的正式会议，这样使文档制作量最少化。

后面是关于敏捷方法的由来以及产生原因的论述，这里着重说一下CASE,再一次加深我对于CASE 以及情景Case 的区分，我会把我学习中遇到的问题，以及自己的感悟都写在里面，写给自己看同时也希望能够帮助正在学习的你我他。
最重要的是，我看到一句，更新了我在网上查到的资料，就是，敏捷开发方法允许了开发团队把主要精力集中在软件本身，采用迭代的方式完成软件一系列的软件描述、开发和交付，这个和我之前所查到资料后想到的原因是一致的，这一点让我感觉很欣慰，

之前对于极限编程毫无任何了解，在看了这一段之后，知道极限编程其实就是包含在敏捷方法中的作为敏捷开发方法的代表方式。但是，后面所论述的关于极限编程与更传统方法的集成，这一句不是很了解，之前在上一章的时候，我就注意到，软件方法之间的集成，我始终不是很明白是什么一个意思，估计随着后面学习的深入，我能自己解答这个问题。这个地方存疑，打上重点疑问符号。

后面主要介绍了，在几个类型的系统开发之中，敏捷方法的成功之处，主要是一些应用场景，其中主要包括：1软件公司正在开发并准备出售的小型或者中型产品，2机构内部的定制系统的开发，客户会有一个关于参与到开发过程中去的明确承诺，且没有许多来自外部的规章和法律等影响。 另外由于敏捷性方法应用到大型化系统工程中时，可能存在一些不可预知的风险，所以，在经过一些改进之后敏捷性方法才能应用于系统安全性要求极高的领域、同时，敏捷性方法在应用在具体工作中时候会存在很多问题，这个也是需要规避的。再者，由于敏捷性方法根本上强调的是文档描述的最小化，但是软件开发不可避免会需要一个文档告诉相关操作者如何进行操作，所以，文档对于敏捷性开发，我认为依然是需要的，另外，作者还提到了关于在产品交付后继续跟进软件迭代的困难，是需要用户参与其中，因为后期团队解散，那么由于没有文档描述以及支持，这个项目可能就没办法做迭代，总结起来就是，敏捷性开发有利有弊，需要在不同时期不同产品进行针对性使用。

后面主要是介绍了计划驱动软件开发和敏捷性开发的区别和优劣，思维导图我任务对于我来说很有用，在计划驱动的方法中，迭代发生在各个活动中，用正式文件在软件过程的各个阶段之间进行沟通，例如需求将演化，最终将产生一个需求描述，这又作为设计和实现过程的输入信息。在敏捷方法中，迭代发生在所有活动中，因此需求和设计是一起开发的，而不是单独进行的。

计划驱动的软件过程可以支持增量式开发和交付，分配需求并将设计和开发阶段计划为一系列的增量式完全可行的。敏捷过程并非一定是围绕代码这个焦点，它也可以产生一些设计文档。正如在下节中介绍的，敏捷开发团队可能决定去完成一个文档的“spike”（这个词语需要查一下）团队生产出一个系统文档，而不是生产处一个新版本系统、实际上，大多数的软件工程都包括计划驱动的开发和敏捷开发实践、

另外，计划驱动开发和敏捷性开发之间存在取舍问题，主要集中在下列几点：1相关系统，对于开发之前的计划和设计是否重要，2增量交付是否可行，3开发的系统有多大，4开发系统类型，5预计的系统寿命是多长………诸如此类，归根结底其实就是在了解 计划驱动开发和敏捷性开发之间的优劣之后可以自行判断的东西。

下面这一小节是关于极限编程的，极限编程叫做XP，也许是最为熟知和流行的一种敏捷性开发的方式，这里，我认为如果说测试这个工作岗位，可能极限编程相较于计划驱动的开放更需要测试人员有更好的职业技术，因为极限编程会对所有测试进行成功执行，并且在写代码之前为每一个任务进行开发测试。
另外，这一章节，图3-3我认为十分重要对于理解极限编程的运作原理，这个思维导图很好，给自己画个重点。
增量式开发是通过系统小的频繁的版本来支持的，其间所采用的对需求描述的方法是基于客户故事情节或脚本，这样的故事情节，或脚本作为决策哪些功能需要放在增量里的依据，这个地方我的理解是，所谓的客户故事情节或者说脚本，其实就是最开始版本的文档也就是软件描述。至于理解对与错，需要后面继续学习的时候进行证伪。
我认为最有意思的是，在XP过程中，更加突出了客户作为开发团队一员的作用，即随时可以提出意见，这可能是大多数软件开发公司所用的方法，通过我过往与朋友聊天过程中可以感觉极限编程我估计是目前较为普遍的一种软件开发手段，当然和我之前说的一样，需要后期学习之后进行证伪。

这里有一个很重要的问题，就是在我看下面这个示例之前，我并不能很好理解所谓故事情节，看了这个处方示例之后，我豁然开朗、确实学习就是证伪的过程。

在需求发生变化的时候，未实现的脚本发生改变或者被忽视掉。如果需要对已经交付的系统进行变更，要制作出新的脚本卡，而且客户需要重新决定是否这些改变应该有比新功能更高的优先级，我认为这句话很重要，就是说，在极限编程中，所谓的故事脚本，可以 根据优先级进行变更。

同时，极限编程将增量式开发推向极致，新的软件版本一天中要构造好多次，移交给客户的增量大约是每两周一次，从不拖延发布的截止日期，如果有开发问题，将咨询顾客，并将功能从计划发布的版本中移除。当程序员创建出新版本的时候，必须运行所有现存的自动化测试以及对新功能的测试。只有当左右测试都成功执行之后软件的新版本才是可接受的。

同时，增量开发有一个问题，就是有可能使软件结构变坏的可能，所以，极限编程应对方法是通过对软件的不断重构，这就要求团队人员不断查找可能需要改善的地方，不断进行改善，我认为，目前熟知的所有app都是属于极限编程的一种，至少目前是这么认为。

另外，极限编程中很关键的测试特性主要体现在：测试优先的开发、来自脚本的增量式开发、用户参与测试开发和有效性验证、自动测试系统的使用。

这里提到，测试过程中用户的作用是将要在系统的下一个版本中实现的故事情节开发接收测试。值得注意的是，虽然极限编程会有很多测试工作，但是，开发完成后依然要进行测试复查和进一步地编写测试程序。

极限编程中另一个有创新性的实践是程序员结对开发软件，结对编程的有点是支持共同拥有软件和共同对系统负责，担当非正式复查过程，有助于支持重构，整体来说，结对编程在极限编程中有很大作用，利大于弊。

后面主要叙述了，敏捷性项目的管理，区别于常规计划驱动开发的管理方式，一般使用Scrum方法，主要是注重迭代开发的管理，而不是管理敏捷软件工程的专门技术方法，主要特征是1产品被分解成一组可管理的和可被理解的块，2不稳定的需求并不阻碍工程进展3整个团队的所有事情都是可见的，因此改善了团队的沟通，4用户看到增量的及时交付，且得到对于产品如何工作的反馈，5客户和开发者之间彼此信任，创造积极文化，每个人都希望项目成功。

后面介绍了，敏捷方法的扩展，主要是可以运用于大型软件系统工程，做出一定的调整，但是敏捷方法必须去适应大型工程，具体调整主要是3地方，1是大型系统得预先设计系统文档，不能只关注代码，这个和我之前自己思考的计划驱动和敏捷性融合不谋而合，我比较满意自己，2是跨团队沟通机制的建立，3持续集成，当前大部分大型项目依然比较抵触敏捷性开发。这一章学到很多，有一个是关于学习上的，是必须要仔细看每一个章节的最后要点部分和练习！！

第四章

主要是介绍软件需求的概念，以及涉及到的过程，很重要的是需要区分一下，用户的需求和系统需求的概念，了解导出、分析和有效性验证等主要的需求工程活动，以及这些活动之间的关系，另外了解需求管理的重要性。

用户需求和系统需求的分离是很重要的，我觉得这个例子举的很好，着重符号，用户需求是用自然语言加图的形式给出的，关于系统需要提供哪些服务以及系统操作受到哪些约束的声明。系统需求详细地给出系统将要提供的服务以及系统所收到的约束，系统需求文档有时候称为功能描述，应该是精确的。它可能称为系统买方和软件开发者之间合同的重要内容。后面就给出一个管理系统的例子来说明用户需求是怎么样拓展称为系统需求的。这里着重强调了，这里的系统需求更加偏向于传统计划驱动开发，因为主要是大型系统需要在开发之前就有一个明确的计划和需求工程。

1功能需求主要是包括对系统应该提供的服务、如何对特殊输入做出反应，以及系统在特定条件下的行为秒速。在某些情况下，功能需求可能还需声明系统不应该做什么。
2非功能需求，服系统提供的服务或功能给出约束，包括时间约束、开发过程的约束和所收到的标准的约束。非功能需求经常使用于整个系统而不是个别的系统功能或服务。

需要注意的是需求并不是独立的，一个需求经常会产生或是约束其他的需求，因此系统需求并不仅仅是要具体说明系统所需要提供的功能或服务，同时需要明确确保这些服务和功能正确交付的一些必要功能，

虽然关于功能和非功能需求的描述很绕，但是结合例子以及网上查询资料大概能理解一些。
后面就是论述功能需求的定义，我的理解就是功能需求就是对于系统需求提供的相应技术性的功能。需要注意是大型系统对于功能需求描述大多数时候都有矛盾出现，需要深入分析和交付客户之后才可能暴露出来。

和我想的一样，非功能性顾名思义，就是那些不直接关系到系统向用户提供具体服务的那一类需求。对于非功能需求，我认为给出的图示很清晰的表示了各种需求之间的关系，主要分三个大类，一个是产品需求，2个十机构需求，3是外部需求。但是需要注意的是，非功能性需求存在一个普遍问题就是，用户或消费者经常建议把这些需求作为总的目标，比如易用性，系统的恢复性，或是快速的反应能力。目标固然能提出好的计划，单也带给开发者许多问题，因为这会给系统交付之后在户和开发者之间引发争议。在实际过程中，对需求描述的量化通常是很困难的。对非功能需求的量化验证成本很高。

软件需求文档SRS是对系统开发者需要实现什么的正式陈述，包括了用户需求和系统需求。我认为就是一种需求的标准化文档，极限编程不同于常规的软件需求文档而是一种增量式的收集用户需求，这几个章节反复提到增量式，我对于增量式印象很深，在网上查一些资料后发现不是一个专业术语，而是简单一种描述方式。

需求文档中内容的详细程度，取决于索要开发的系统的类型以及所使用的开发过程。要求极高的系统需要有详尽的需求，因为安全性和信息安全性都需要详细的分析。

这里需要注意的是出现了一个IEEE标准的需求文档结构， IEEE标准文中所说是一个通用的标注，之前我在其他地方见过IEEE，这里第一次接触相关内容，着重符号，后面还要仔细研究一下。

需求描述就是在需求文档中写下用户需求和系统需求。系统需求是用户需求的扩展板，是软件工程师开始系统设计的七点。系统需求添加了许多希捷内容，解释如何能让系统提供用户需求，他们可以作为有关系统实现合同的一部分，因此它们是对系统的一个完备且详尽的描述。需要注意是系统需求的描述或多或少 会添加一些系统应该如何设计和如何实现的要求。

自然语言目前是重要的描述系统和软件需求最广泛使用的方法，因为自然语言会有修饰，所以为了避免无解，有些准则：1标准格式，2使用一致性的语言来区分强制性需求和可选性需求，3对文本加特殊效果来强调关键性需求，4尽量不要用工程性语言描述，5需要把需求原理和用户需求联系起来。

结构化描述是自然语言描述的一种方法，可以更好的发挥自然语言的优势同时可以限制误解的部分。结构化描述，我理解主要是按照表格形式进行概括，具体的需求描述要求，在4-10下方有相应要求，由于过于简洁易懂，不在这里例举。

需求过程这一块，主要包含四个主要的点，一个是系统可行性研究。二个是需求导出和分析，三个是需求描述，四个是需求有效性验证。实际操作中的需求过程的四个活动是在相互交错迭代中的。
这个地方又一次提到了螺旋模型，这里的螺旋模型主要是提供开发方法准许我们将需求处理为不同详细程度。关于需求的导出和分析，主要分为几个步骤：1需求发现2需求分类和组织3需求优先权排序和协商4需求描述，同时需求的导出和分析是一个很苦难的过程，主要是由于1项目信息持有者表述不清晰，2系统信息持有者表达缺乏专业性3不同信息持有者有不同需求表达方式有不同，4政治因素影响系统需求，5进行需求分析的经济和业务环节是动态的一直在变化。文中后面提到了需要用表格形式归纳总结需求
需求发现，主要总结起来就是通过对话或者说 采访 和 脚本 用例 以及实践的方式对信息持有者进行需求的自我总结。这是我的认识。
前面看了关于需求的大部分内容，后面对于已知的需求要进行需求验证主要是进行：有效性检查、一致性检查、完备性检查、真实性检查、可检验性检查。对于需求的有效性验证同时也有固定的一些验证技术，主要是1需求评审，2原型建立，3测试用例生成。
需求管理规划主要就是对已知的需求 进行归档的过程，主要的环节是：1需求识别，1变更管理过程，3可追溯策略，4工具支持，对于小型系统，可能不必使用专业化的需求管理工具，需求管理过程用字处理器中的工具、电子表格和微机数据库就能支持。然而，对比较大的系统，更多专业化工具的支持是必须的。所以需求管理，我认为是很重要的。我觉得最重要的地方在于在于需求的归档的整理，不知道在之后的工作中会以怎么样的一个形式呈现出来，需求变更管理其实我认为是对于需求管理的一种补充，是在需求文档被确认之后对系统需求的所有变更提议，分为三个阶段：问题分析和变更描述、变更分析和成本计算、变更实现。我认为通俗来讲就是，对于之前管理档案的进一步归档。

第五章

这一章，主要是介绍系统建模的，看到标题我就很疑惑了，什么是系统建模。我上网查阅了一下资料。归纳起来就是对于软件系统的设计思路进行具体的模型建立，不知道我现在这么理解是不是准确，后面来看看。这一章，主要是讲了用图形模型表示软件系统，理解相关术语，了解建模语言UML其中的图表类别，还有模型驱动中包含的思想，这里又 出现了一个模型驱动，我现在不知道都是应用于软件系统建立初期，这个模型驱动和之前所讲的计划驱动是否是并列关系，这个需要后面验证一下，这里打一个着重符号，

系统建模就是建立系统抽象模型的过程，每一个模型表示一个系统不同的角度或方面。系统建模通常意味着用一些图形符号表示系统，现在几乎都是用统一建模语言中的符号，然而也有可能要建立系统的形式化模型，其通常作为详细的系统描述。系统建模主要分为需求工程建模和设计过程建模，系统模型的很重要的一个方面是在于它摆脱了所有的希捷内容，系统模型是系统的一个抽象而不是一个具象替代表现。主要可以从以下几个方面表述系统：1外部上对系统上下文和系统环境建模，2交互上看对系统环境之间或是一个系统各组成部分之间的交互建模，3结构上看对系统的体系结构和系统处理的数据的结构建模，4从行为上看，它是对系统的动态行为和它对事件的响应方式建立模型。

说一句题外话，这一章开头多次提到UML，加深了我对UML的记忆和理解，在这里，我想说，还是要反复的看和记忆才能熟练的掌握至少这个东西的意思，UML主要是通过类型图进行表述的，主要可以分为：活动图、用例图、时序图、类图、状态图几种，在某些情况下，这些模型图的内部表述可以不必太完整，比如工程师之间讨论时，但是作为详细系统描述的时候，必须是完整和准确的，是因为它们是产生系统源代码的基础。

下一小节是讲关于“上下文模型”的，系统边界是必须确立的，但是确立之后存在和另外一个边界之间的联系问题，上下文模型主要我认为就是解决这个问题的，上下文模型通常表示某一环境包括几个其他的自动系统，然而它们却没有描述其他子系统之间的以及待描述的系统与它们之间的关联关系的类型，简单的上下文模型要同其他模型结合在一起使用，通过两个活动图，大概能理解上下文模型的意义所在。
交互模型，所有的系统都会涉及一些交互，所以交互模型就是因为这个原因产生的，交互模型的建模方法主要有两种：一种是用例建模，该方法主要用来为系统与外部参与者之间的交互建模，二种是时序图，该方法用来为系统各部分之间的交互建模，会包括一些外部因素，这两种建模方法有时会在一起使用，因为这个地方有点绕，我在笔记本上手绘了一个思维导图，以便于自己理解。

用例建模主要实现方式是通过讲故事，就是所谓的脚本模式进行建模来描述用户对系统功能的期望，用例建模需要用简单的文本进行描述，便于理解，一般情况下会用表格形式进行表述，时序图，主要就是描述在用例中的交互顺序，时序图中有一个我认为比较关键的点就是面向对象的需求分析，在面向对象的需求分析过程中，使用队形类对现实世界终的实体建模。我们有可能会建立多个不同类型的对象模型，有的用来表示对象类之间是额部和联系的，有的用来表示如何将对象聚合在一起产生其他对象，有的用来表示对象与对象是如何交互的，每一个模型都表示与所描述系统的独特信息。

当开发面向对象的系统模型时，我们用类图来表示系统中的类和这些类之间的关联，这里我在想，我读这本书经常出现让我感觉很疑惑字词，感觉不应该出现在这个地方的词语或句子，但是表达的意思又不像自然语句中所表述的那样，这个需要转变一下思路来理解一下，
最开始我是不太理解这里的类是什么意思，但是里面有一句话很好，就是：UML中的类图可表示为不同的希捷层次，当我们要建立模型时，第一步通常是观察时间，确定重要对象，然后将它们表示成类。类图能够表示出有多少个对象参与这种关联当中，

在表示类与类之间的关联时，用尽可能最简单的方法表示类可能会给我们带来很大的便利。同时在下一小节讲了泛化，这个我认为是在做类图的延伸，泛化主要是用来管理复杂性，不需要去做每一个实体的所有细节特性，在建立系统模型中，检查系统中的类，看看它们是否还有继续泛化的空间，这是常用的。泛化关系中，低层次是子类，继承超类的属性和操作。至于聚合，UML提供一种特殊类型的关联，我理解就是组成部分组成整体的一种关联形式。

行为模型，行为模型就是描述系统运行时动态行为的模型，表示当系统响应来自所处环境的刺激时或有可能发生的事情，表达形式主要是：数据和事件，这里我看了一下DFD数据流图，但是没看懂，这里做一个疑问，后面来解决。
比较有代表性的产品就是业务系统，我的理解是类似于电销机构的打电话系统，会用到行为模型进行设计和处理。数据驱动模型描述一个动作序列，该动作 序列设计输入数据的处理和相关输出的产生， 在需求分析过程中，数据驱动模型非常有用。数据驱动模型时最早图形化软件模型之一，这是不是意味着目前我所用的pc图形化界面都和这种类型有关呢 ？数据流模型有用主要是因为它跟踪并记录了与一个特别过程相关的数据是如何通过这个系统的有助于帮助分析人员和设计人员理解正在发生什么。这里着重需要注意，都可以表示处理序列，但是数据流图和时序图示有区别的。

事件驱动模型表示系统对内外部时间的响应方式，和之前几个图类似，都是应用于不同场景下的不同模型图，这些图之间的并列关系，我需要一个思维导图辅助理解，

模型驱动工程师软件开发的一种方法，简写是MDE，有些人认为这样做可以提高软件工程的抽象水平，使得工程师不必再去关心编程语言的希捷或执行平台的特性，但是呢，对于这么一个方法，有支持者也有反对者，主要争论在于抽象化的优劣和程度，我认为主要取决应用对象和，操作方式。模型驱动体系结构，主要有三种类型的抽象系统模型，1计算独立模型，2平台独立模型3平台特定模型，模型驱动工程背后的基本概念是，模型向代码的完全自动化转化是可行的，但是这里我有一个疑问，这里说UML是一种支持软件设计和记录软件设计的语言而不是编程语言，让我对UML表达的意思产生的一些疑惑，留作疑问，打问号，目前为了建立UML可执行的子集模型类型主要包括：1领域模型2类模型3状态模型。
今天的读书任务，我觉得完成我比较满意，比昨天理解能力以及脑袋反应速度有所增加，明天目标是读四章，虽然说不至于所有知识我都已经消化掉，但是通过查阅资料，以及看了一下相关问答，感觉至少对于一些基础知识能够比之前状态好了很多，加油。