1
我看了第109页讨论瀑布模型的问题，‘瀑布模型在软件工程中存在局限性：1，各步骤之间是分离的，但是软件生产过程中的各个步骤不能这样严格分离出来；2.回溯修改很困难甚至不可能，但是软件生产的过程需要时间回溯；3，最终产品直到最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用。最终产品直到最后才出现’。为什么最终产品只有到最后才能出现，不是应该在设计时就把所有会出现的问题考虑清楚。 我查了资料，有关于最终产品的定义：‘最终产品是“中间产品”的对称，是一定时期内生产的而在同期内不再加工、可供最终消费和使用的产品。’，根据我的实践，我认为最终产品在最后才会出现是因为平日实践过程中会出现各种各样在预料之外的问题，慢慢探索慢慢实践才能得出最终产品。
2
我看了第166页的快速原型调研，利用用户参与式设计，省了很多时间和精力，利用快速原型调研可以省去了很多时间和金钱，但是测试的时候都只是部分的测试，不知道当全部合起来时候会有什么不一样的偏差怎么办。 我查了资料，有这些说法：快速原型开发方法的优点如下：‘1）该方法可以达到非常迅速的知道用户反馈的信息，方便用户与开发者的交流，从而动态地完善需求分析和系统设计，用原型启发、揭示和明确用户的需求。2）该方法虽然能非常迅速的知道用户反馈的信息，但是更强调用户参与，原型能激活用户和开发者的思路，以便快速地试验新思想、新技术，有利于评价、完善开发方案，有效地利用资源。3）该方法不仅减少了软件开发风险，更有助于提高软件质量和软件生产率。4）如果该产品渐增式开发，维护、扩展的话，你觉得哪个方便呢？当然还是选择快速型原型开发方法了。快速原型开发方法主要存在以下问题：1）原型开发时难以管理，无法备全全部资料，导致存在质量隐患。2）难以确定原型，原型目标偏离太多，则会导致系统失效。3）比较费劲的是要把所有子系统相互融合的形式放到整个信息系统中。4）由于多次反复，导致用户失去开始时的耐心，在不耐烦的情况下选择了不合格的原型当做最终系统。值得注意的是，就开发过程中要反复改进设计这一点来说，原型法和瀑布式方法是互补的，但原型法和瀑布式方法并不相互排斥，在开发原型和改善原型的过程中并不排斥分阶段进行需求分析、系统设计、编码测试等。另外，考虑到原型法可能引起的质量问题，将原型法只应用于瀑布式开发的需求阶段，一旦完整地定义了需求，原型即被抛弃，按照瀑布式开发方法开发系统，这样尽管成本要增加，但瀑布式开发需求不完全的问题得以解决。在质量要求很高的系统中经常采用这种方法。’根据我的实践，我认为快速原型模型还是应该存在并广泛使用，因为在设计过程中，时间和金钱的考虑占的比重是比较高的。
3
我看了第206也关于怎样定义典型用户下面的注意的一句话：我们的软件不是为所有人服务的，有这个问题，为什么一个软件就不能为所有人服务。 我查了资料，有这些说法因为每个软件的试用人群不同，根据我的实践，就像手机上的app就算支付宝在绝大部分中国手机里都会存在，那那些还有使用按键机的老人和那些不使用支付宝的外国人，他们就没有支付宝所带来的服务，所以软件也都是只针对那些他们，所适用的人的。
4
我看了第232页关于代码完成的文章，所有的代码都写了所有的工程都实现了不代表这个产品就完成了，因为产品中还会有bug,而且各个模块之间还有可能存在很多问题。但是代码完成了，不就已经是测试了所有的功能和代码。 我查了资料，有这些说法：所有代码都完成了，也许我们现在还有许多缺陷，还有一些测试相关任务，这些要留到以后稳定阶段才能全部解决。根据我的实践，之前做课设的时候很多时候代码已经完成了，但是还是会有很多需要修改的部分，如果是有图形界面的，就是一些不需要在代码上改动，只需要在软件上作修改就好了。
5
我看了189页提出也有开发和测试搞不定的问题，难道开发人员看不懂普通文字，需要翻译成规格说明说才能懂吗。 我查了资料，有这些说法，测试用例说明书，通常定义为对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。在软件产品开发中用的非常多，但在项目开发中，重要性进行经常被忽视，很多项目组都是不做的，或者是为了敷衍编写的。敷衍是有很多原因的，各方不重视测试，需求多变导致测试层本大幅增加、项目时间节点紧，因此很多测试过程会被简化。很多项目组最后只会有下1-2个左右的测试人员，或者是开发人员做兼职测试，在编码结束后，就上系统点点，然后提交客户了；客户验收也是同样，验收平台搭建好后，走走流程，可能脑袋里面会想，怎么走流程可以把所有的流程都过一遍么，缺乏系统和专业的考虑。，根据我的实践，规格说明书是简洁明了的例举了在开发中需要的需求，就相当于我们平常的需求分析，需求分析也往往是最重要的。
