622

在第4篇 开发，第17章 快速软件开发 中提到了极限编程，其中P244关于适合极限编程的原则中的第3条：人（而不是过程）是通过结对编程、集体对系统代码的所有权、可以忍受的开发过程而无需超额工作小时来运作。

我的疑惑是：为什么极限编程就要结对编程？

首先，极限编程是最流行的敏捷方法，敏捷方法就相当于快速的新陈代谢，不断改进，快速开发出新版本，每一次的增量都很小。而如书中所说，结对编程的效率和单独编程时一样的，它的好处是可以减少错误的发生和返工，并让两个人一起对代码负责。然而对于代码量本来就很少的情况下，它出错的概率也是很小的，且结对编程需要一个磨合期，并不是所有人都能很好的配合，所以在刚开始，结对编程的效率肯定不入单独编程。就代码责任方面，我认为如果有好的赏罚制度的话，单独编程的效率更高。

就我看来，结对编程更适合长时间的软件开发，而不是快速软件开发。结对的两个人要实力相当，如果随意搭配，反而互相影响，降低效率。

 

在第6篇 管理，第25章 人员管理 中，P368提到：除非是一个短期任务需要编程语言的专业知识，否则最好是选择能解决问题或有领域经验的人。学习一门语言相对较为容易，而为解决复杂问题获得深层次的概念性知识则要困难得多。

我的疑惑：学习一门语言也不容易啊。

在软件公司，最好找的就是编程熟练的工程师，他们可能对别的领域不甚了解，但至少熟悉编程语言。而世界上的领域千千万万，选择有领域经验的人实在很难。假如做一个胰岛素泵系统，懂编程的医生很少很少，难道要找一个医生来加入到项目组中现学编程？我觉得这是荒谬的和不切实际的。我觉得应该是让编程的工程师和医生一起认真地探讨需求，用一种医生和工程师都懂的形式化语言来详细地描述需求，之后由工程师编程。期间可以周期性地开几次会，商讨需求的变更或编程中遇到的难以实现的需求。这样才能使得软件开发的效率最大化。

 

在第2篇 需求，第9章 要求极高的系统的描述，在风险分析和分类中（P119）作者将风险归为无法忍受的、能满足实用要求的和可接受的。

我的疑惑：何谓可接受的风险？

风险就是说可能导致不好的结果的，而可接受的难道是说这结果虽然不好，但是不会致命？作者举的例子中，在胰岛素泵系统中，断电和过敏反应都是可接受的风险。这可能是作者自己的想法，过敏反应怎么可能是可接受的，对于有些人来说，过敏可以致死。所以说风险分析有主观性，每个人的分析结果肯定不一样。在要求极高的系统中，每个人都是不可忽略的，即使大部分人认为是可接受的，也要为了那一小部分不可接受的人来解除风险。且解除风险是一劳永逸的，不能因为成本太高的原因而去放弃一小部分人。

 

620

P57 “大型软件项目一般都不同于早先的项目，因而管理者就算有在计划中降低不确定性的经验，也很难遇见问题的出现。此外，计算机和通信技术飞速发展，早先的经验随之变得过时了，其中的教训不能在新的项目中发挥作用”

 

技术的发展的确很快，但是开发过程中的经验教训应该还是能够有某些普适意义的，能够提供一些借鉴。常做大项目的人，做起大项目来还是比一般开发者有优势的，这个优势应该就是来自于经验了。

 

P66 “风险识别可以通过项目组集体讨论完成，或者只凭借管理者的经验进行。”

作者讲“风险”包含了人员风险（人员培训跟不上，关键人员离开），机构风险（管理层变了，财务问题），这些风险跟“人”的相关性很大。通过项目组集体讨论，我觉得出于人际关系和对上级的敬畏，应该不会有成员会随便提这些“风险”的，因为这个是一种“不信任”了，因此项目组本身的集体讨论，可能更多得到技术相关的内容。我觉得风险识别，应该由第三方来做，然后将报告提交给项目组上面的管理者，管理者再来将其中何时的部分透露给项目组的人，其余的只供自己参考。

 

P82 接口描述 中 第三点，“数据的描述”。

没明白这一点的具体含义，是指每一个信号位的定义吗？如果是，我觉得这应该是第二点数据结构的内容吧。

 

P95 最下 “然而因为它们（场景和用例）集中在交互上，它们对于约束、来自间接视点的高层业务和非功能需求，抑或是领域需求发现都是不奏效的。”

我觉得有时候场景和用例可以是“奏效的”。在场景的描述中，比如，文中LIBSYS论文下载的场景中，提到了很多领域相关的流程，从中我们应该能发现一些领域需求的，比如“出于版权，一些文档只能输出到打印机上”（前文中讲了这个是领域需求）。

 

P97 测试用例生成 “如果一个测试的设计很困难或是不可能的，那通常意味着需求的实现将会很困难”

我觉得测试的设计难度与需求的实现难度应该没有太多必然的关系，对于不同的项目，两者可能正相关或者负相关，或者没什么关系，这个“通常”，准确吗？

 

P114 结构化方法

到底何谓结构化方法？是指一套固定的流程吗？还是说表示上的结构化？

 

P123 图9-6 安全生命周期

这个生命周期只是一个单独的流程，难道安全生命周期不需要有类似回路，螺旋样的不断迭代、进化的过程吗？

 

P137 Tail公理的验证

这里的推导验证相当繁琐，这种形式化推倒验证是否能自动完成？否则的话，如果对一个“稍大一些”的系统采用这种形式化方法，写出经过严格验证过描述是不是太耗费了。

 

P151 容器模型

这里的“容器”，如何来理解，是说“系统是盛放数据的容器”这个意思吗？或者是别的什么？

 

P164 “因此，分布式系统就需要一种软件来管理这些不同的部分，以确保他们能通信和交换信息。中间件就是这样一种软件，它位于系统的不同分布式组件之间。”

中间件本身也是分布式系统的一部分，那么中间件运行的系统，处理器是什么要求呢，他运行在什么机器上呢？他是怎么实现去粘合不同处理器不同系统之间的通信的呢？

 

P166 胖客户机，瘦客户机

一个想法：以后如果我们的操作系统都是直接基于互联网的（Chrome OS？），是不是很多概念就要重新来讲了？

 

P170 CORBA

没怎么看明白，特别stub，skeleton那一部分。这里使用图形说得很形象化，但是对于没有实际代码经验的人，显得太概念性了，让人难以从具体实现方法的层次得到一个认识。能否给点具体的例子。

 

P175 面向服务系统体系结构的优势

动态的绑定服务的确带来了很多的灵活性和便捷，但是如果软件中包含越来越多的web service，软件就会变得越来越不独立，软件提供商越来越不能控制软件在客户手里的表现了，谁能保证客户能不能连接到服务提供商呢，也许提供商的测试环境与最终用户差很多，提供商无法“控制”软件在客户处的表现。这应该是很大的一个劣势了。

 

P221 “虽然聘用专家进行硬件设计是常有的事，但几乎没有机构聘用专家进行界面设计。因此，软件工程人员往往既要负责用户界面设计，又要负责界面的软件实现。”

我觉得这种想法已经逐渐过时了，现在已经有独立的UI公司了，专门负责界面的设计。很多软件的界面都是由UI公司开发的。微软也发布了Microsoft Expression Blend，让设计者与开发者可以分开工作，各自关注于自己的专项。软件向着用户友好发展，UI设计的专业化，几乎是肯定的。

 

P224 表16-2 各种交互风格的优点和缺点。

表中将“需要键入的太多”作为了自然语言交互方式的一个确点。我觉得这是不合适的。由于自然语言是人最熟悉也最自然的交互方式，虽然要说的“字”可能的确多一些，但是相对于键盘输入，这依旧对人是很轻松的，动动嘴就行了。自然语言交互最大的问题应该还是在于机器怎么准确的理解人。

 

P227 “如果需要精确的数字信息并且信息变更相对较慢，信息应该以文本形式表示。如果数据变更得快或者数据之间的关系很重要，则应该使用图形形式表示”

用文本还是图形，应该有很多方面要考虑，而不仅仅是数据特点来决定。比如系统资源，对变更得快的数据使用图形表示，是很费资源的，系统不一定负担得起。再比如系统的整体风格，如果系统是一个很华丽的图形化界面，在里面放入文本信息也会显得很突兀。因此，具体的表示方法应该考虑多方面的因素，最重要的还是尊重用户的习惯。

 

P235 （用户界面评估方法）“在软件中嵌入一段统计代码，以收集最常用的功能和最容易犯的错误的信息。”

 

这种后台的收集，会不会是用户愿意的呢？对于某些敏感的应用，从用户操作中就可能泄露出用户隐私信息，软件投入使用后，用户也许不能容许软件提供商收集自己的操作序列了。如果是软件收集操作，然后软件智能的做出方便用户使用的界面改变，那应该很不错很强大。

 

603

在本书的12.1节、164页，提到对等系统体系结构（P2P）。在我看来这种体系结构具体化、实例化就是我们现在常用的像电驴、酷我音乐盒这样的软件。我想知道这正软件的安全性是否很难保证。如果别的机器通过互联网从一台机器上下载资源，那么此台机器的其他资料是否存在被盗取的安全隐患；还有就是，从别处下载的资源文件，怎么才能保证其安全、绿色，而没有隐含的病毒呢。

 

本书的12.3节、171页，讲到CORBA（Common Object Request Broker Architecture公共对象请求代理体系结构）时有这么一段，CORBA对象接口使用标准的的接口定义语言（IDL）。如果一个对象想使用另一对象的服务，那么就通过IDL接口访问这些服务。CORBA由一个独特的标识，叫做互操作对象引用（IOR），当一个对象请求另一个对象上的服务时使用IOR。我理解IOR就是一个像信号射频传输时的协调器一样的工作站，所有的对象要和外部进行连接时都得通过它，而各个对象之间是不可见的。这样理解正确吗。

 

本书第十三章中描述，应用体系结构，可作为开发团队工作的组织方式。我之前与同学合作过完成过一个图书管理系统。当时我们就在图书馆借了几本书，参照了一个已有的应用体系结构来分配团队成员的任务。但是在具体实施工作时发现，如果只是死板的按部就班，也会出现很多的麻烦的。根据应用体系结构的系统，特别是面向对象的系统，来分配任务时。人们会很轻易的按照类的划分来处理。这样往往会出现团队的不同成员所写的类之间互相重叠、而不是一个整个的模块的的情况，在一个人独立编码时，无法运行、调试，导致在集成不同成员的工作后开始调试时，出现一些致命的错误，必须返工。有时还会出现不同成员的任务之间存在着极大的相似程度，可以复用的情况。如果这样的任务一个人承担，不然会大大节省工程的时间。

 

在本书14.1节、195页，Java的线程控制，可处理并行任务。学过Java，也用过线程控制。但是我一直不明白一点，只能串行运行的冯诺依曼体系结构的计算机是如何处理多线程的呢。

 

本书第十五章、208也页，在描述实时系统存在的基本问题时说到：Java虚拟机的实现对于各个计算机是不一样的，所以，相同的程序在不同机器上可能有不同时序行为。我的问题：不是正因为有了Java虚拟机，才能实现平台无关的吗。还是说Java的平台无关不包括实现相同的时序行为。

 

在本书的16.1节、369页，有一个LIBSYS系统的基于表格的界面。我曾经也用Java Swing写过类似的基于表格的系统界面。用Eclipse运行，但是几乎所有的组件都不能正常的自动显示。需要人工的再界面上点击鼠标才能完全显示出来。

 

本书讲的十六章是用户界面设计，整章贯穿始终的都是用户对于软件系统设计的至高的地位。一个人间系统设计出来就是给用户使用的，所以从它的需求分析、设计完成的整个过程，用户的意见都具有最高的优先级。但我在使用Microsoft Visual studio 2008时却发现一个造成用户使用障碍的缺陷。操作界面的边栏有个叫做服务资源管理器的标签。只要你把鼠标移动到它上面，服务资源管理器就会自动的弹出来。鼠标离开，它就会自动的缩回去。这个貌似给用户提供了方便，实际上却带来了用户使用的麻烦和障碍。我从来都没有用到过服务资源管理器，但是我几乎每次在用VS2008时，鼠标都会不小心滑到此标签上，然后服务资源管理器就会弹出来。如果说是目前没有任何任务的话，弹出来，再缩回去就行了。如果目前VS2008有任务，哪怕只是处在编辑状态，鼠标掠过这个标签VS2008就会无响应一会儿。

 

本书16.4节，提到用户原型界面构造的一种方式——情节串联图版。我对这个不是很明白，不知道到底是怎样的的形式。老师有没有用此种方式构造的用户界面原型的例子。还有书上说这种方法的实用性稍差。但我的理解是，对于非专业的用户来说，这种图形化的表示方法再好不过了。而用户原型的一个最重要的作用不是开发人员与客户的交互吗。

 

本书的第十七章讲的是快速的软件开发。微软的产品，特别是windows操作系统，是在巨大的商业压力下，采用快速的软件开发方式开发的吗？我的电脑上装的是vista,几乎每周都会发布更新，这个可以看做是一个新的循环产生的一个新的软件增量吗？还是，每三年的一个新版本，才是一个新的软件增量。

 

601

第四页1.1.1节最后一段中的SAP系统是什么？

 

第四页1.1.2节最后一段，为什么给予Web的电子商务系统尤其适用非正规开发？其他很多系统不更需要软件和图形设计技巧相融合吗？尤其是游戏。

 

第五页1.1.6节迭代式开发方法最后一句“鲁棒”是什么意思，第四十三页4.2.1也出现了同样的词。

 

第十五页2.2节最后一段的例子中为什么做这种选择会保持他们现有的工作？

 

第二十二页2.2节对于主承包商的模式，我觉得也有一定的弊端，比如在竞标的多个主承包商中，有一个主承包商总体有优势，但在每个单独的子系统中并不突出，而且他竞标者都有各自所长，虽然结果应该是总体强大的那个主承包商中标，但对于这个系统而言在这种模式下，没有达到它本可以达到的优秀程度。

 

第三十三页3.4节二级安全性要求极高的例子中看，这更像是对软件在性能上的精密性要求，这不只在引起安全问题时才会出现，在许多软件中也有要求，所以觉得放在这里有欠妥当。

 

第四十二页4.1.3节基于组件的软件工程适用于大型，中型，还是小型系统呢？

 

第六十页5.2.1节最后一段说要使文档某些章节容易替换，请问如何组织文档才能达到这种要求？

 

第六十五页5.4节表5-3第一行，为什么有经验的职员将会未完成项目就跳槽？

 

第八十九页7.1节问题“如果系统没有实现，机构如何应对”，为什么要放在可行性研究里，而不是风险管理中？

 

520

P21既然人、社会和机构因素在决定系统是否成功地满足其目标上起到关键作用，那我们在软件工程中该投入多大的人力，资金和资源在这一块呢？

 

P17其他工程，比如建筑，需求是如何被描述的，像这类的工程需求一旦定下来后就不能被更改，也就是说它的需求应该能在一次中得到较好的描述，软件工程为何做不到这一点？

 

P24实际工作过程中，既然已经将各个层进行封装，那更改一个层为何往往会带来其他层也需做较大的修改？

 

P27在旧的技术无法满足需求，而新的技术又没有经过全面检验的情况下，对于要求极高的系统，该如何选择？

 

P31对于某些领域，客户因为需求的专业性而与软件开发人员对需求的描述往往不一样，那么是否可以发明一种描述需求的中间语言，客户将需求用中间语言描述，软件开发人员将中间语言转换成最终的语言？

 

P58文档在多大程度上能够反映项目的进度，管理人员还有其他的方法了解项目的进度吗？

P72软件公司在竞标客户项目的时候如何估算自己的成本？

 

P75如果客户和开发者对需求的理解不一样而导致客户不满意，那如何解决合同上的纠纷呢？

 

P91有关需求的一个问题：软件公司是否可以把需求工作过程外包出去呢？有专业做需求分析的公司吗？