读着读着《构建之法》(Build To Win) 越精神的白雪儿的思考

哲学家的宗旨是：我思，故我在

科学家的宗旨是：我发现，故我在

工程师的宗旨是：我构建，故我在

——《工程学--无尽的前沿》

序言：珍惜角色“人”，注重实践“物”

《构建之法》，精读三曲，感触良多。

曲一，语言诙谐幽默，思维独具匠心；曲二，提问勾画，思考获益；曲三，豁然开朗，又困惑不解。软件工程与“人”有不解之缘，“人”用百花齐放的实践构建软件工程。三曲之后，知识概念，不必硬背，只需循序渐进，逐步实践体验，但不得不提出如下五惑。

核心：提出困惑点，分享你我他

第 0 章  目录：

　　1.整体上，软件开发的基本流程是什么？

原文回顾：　　

　　通读该书目录包括个人技术流程团队和流程、敏捷流程、软件设计与实现、软件测试等章节。

引用说法：

　　网上所说，软件开发基本流程如下：

　　1.需求分析

　　　　1.1 相关系统分析员向用户初步了解需求，然后用相关的工具软件列出要开发的系统的大功能模块，每个大功能模块有哪些小功能模块，对于有些需求比较明确相关的界面时，在这一步里面可以初步定义好少量的界面。

 

　　　　1.2 统分析员深入了解和分析需求，根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚列出系统大致的大功能模块，大功能模块有哪些小功能模块，并且还列出相关的界面和界面功能。

 

　　　　1.3 系统分析员向用户再次确认需求。

　　2.概要设计

　　　　2.1 概要设计需要对软件系统的设计进行考虑。

 

　　　　2.2 系统的流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为软件的设计提供基础。

 

　　3.详细设计

　　　　3.1 在概要设计的基础上，开发者需要进行软件系统的详细设计。

 

　　　　3.2 描述实现具体模块所涉及到的主要算法、数据结构、类的调用关系，需要说明软件系统各个层次中的每一个程序(每个模块)的设计考虑，以便进行编码和测试。

 

　　　　3.3 应当保证软件的需求完全分配给整个软件。详细设计应当足够详细，能够根据详细设计报告进行编码。

 

　　4.编码

　　　　4.1 开发者根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求，开始具体的编写程序工作，分别实现各模块的功能，从而实现对目标系统的功能、性能、接口、界面等方面的要求。

 

　　　　4.2在规范化的研发流程中，编码工作在整个项目流程里最多不会超过1/2，通常在1/3的时间，所谓磨刀不误砍柴功，设计过程完成的好，编码效率就会极大提高，编码时不同模块之间的进度协调和协作是最需要小心的，也许一个小模块的问题就可能影响了整体进度，让很多程序员因此被迫停下工作等待，这种问题在很多研发过程中都出现过。

 

　　　　4.3 编码时的相互沟通和应急的解决手段都是相当重要的，对于程序员而言，bug永远存在，你必须永远面对这个问题，大名鼎鼎的微软，可曾有连续三个月不发补丁的时候吗？从来没有！

　　5.测试

　　　　5.1  测试编写好的系统。交给用户使用，用户使用后一个一个的确认每个功能。

　　　　5.2软件测试有很多种：按照测试执行方，可以分为内部测试和外部测试；按照测试范围，可以分为模块测试和整体联调；按照测试条件，可以分为正常操作情况测试和异常情况测试；按照测试的输入范围，可以分为全覆盖测试和抽样测试。

　

　　　　5.3 总之，测试同样是项目研发中一个相当重要的步骤，对于一个大型软件，3个月到1年的外部测试都是正常的，因为永远都会有不可预料的问题存在。

　　　　5.4 完成测试后，完成验收并完成最后的一些帮助文档，整体项目才算告一段落，当然日后少不了升级，修补等等工作，只要不是想通过一锤子买卖骗钱，就要不停的跟踪软件的运营状况并持续修补升级，直到这个软件被彻底淘汰为止。

　　6.软件交付

　　7.用户验收

　　8.维护

　　　　8.1根据用户需求的变化或环境的变化，对应用程序进行全部或部分的修改。

我的认识：

　　　我是因为对流程有困惑而提出这个问题。网上诠释已经很清楚了，一个软件开发流程大体有个认识，但是我认为没有亲身实践，还是无法理解这些流程的可行性，这些概念仍然是比较抽象，我仍然对流程可行性存在困惑，我希望通过这一学期的学习对软件工程的开发流程有着总体上的把握。

第一章  概论：

　　1.怎样才能做到从程序-->软件-->软件企业？

原文回顾：

　　第一章的“ 软件=程序+软件工程”P2页，“A公司要挟用户必须卸载B公司的软件，然后A公司的软件才能运行......道德操守会极大影响软件用户的利益。”

引用说法：

　　书中所言，程序=数据结构+算法    软件=程序+软件工程    软件企业=软件+商业模式。程序（算法、数据结构）是基本功，但是在算法和数据结构之上，软件工程决定了软件的质量；商业模式影响了一个软件企业的成败。

我的认识：

我是因为和书中知识不同而提出这个问题。我的经验，作者所言都有一定道理，我也能理解作者认为商业模式对软件企业的重要性，不过我还是想对“软件企业=软件+商业模式”这条等式深入理解并提出“软件企业=软件+商业模式+其他”这条等式。我认为对于一个企业来说，软件，商业模式，人员招聘，绩效评估，细节决定成败等因素都只是成功的必要条件，而不是充分条件。这些因素中的任何一条如果缺乏或失误，都有可能导致企业的失败甚至死亡，但任何一条的优势或优秀都不能使企业成功。 最片面的莫过于细节决定成败。一个企业的发展，一项任务的完成，都是由无数个细节构成的，除非是非常关键的细节，事关重大战略或决策细节的严重错误，否则一个细节的失误，一般不会导致企业失败。

　　

　　一个企业的成功由多种因素决定，是战略、人、钱、技术、管理等因素综合作用的结果。所以我认为“软件企业=软件+商业模式+其他”的等式可以准确地显示出软件企业成功因素的准确性，当然“软件企业=软件+商业模式”更可以突出软件和商业模式的重要性，我觉得思考过后，两者各有侧重，但我还是尊重作者的思维，以及作者想要传达的良好的职业道德规范下的商业模式才是软件企业经久不衰的硬道理的想法。

　　2.怎样才能研发出符合需求的软件？

原文回顾：

　　第一章的“ 软件工程的目标——创造‘足够好’的软件”P17页，“研发出用户需求的软件......需求来自于实际......不是人云亦云的需求”。

引用说法：

　　书中所言，通过实际的工作收集、推导、提炼需求，并在软件发布后通过实际数据验证需求的确被满足了。

　　网上说法：

需求分析方法一
　　1.获取和引导需求

　　2. 分析和定义需求（Analysis & Specification）

　　3. 验证需求（Validation）

　　4. 在软件产品的生命周期中管理需求（Management）

需求分析方法二
　　1. 对产品功能性的需求

　　2. 对产品开发过程的需求

　　3. 非功能性需求：这也叫“服务质量需求”（Quality of Service Requirement）

　　4. 综合需求

　　

我的认识：

　　 我是因为对词语“推导”不懂而提出这个问题。我的经验，作者所言都有一定道理，我知道需求在软件开发过程中的重要性，但我对书中“推导”一词有些困惑，我仅表述我所理解的意思，欢迎读者提出更好的见解。真正符合用户需求的软件的实现是比较难的，需求分析绝不仅仅是询问客户，让顾客完全决定。那么还有什么因素呢？我所想到的，首先，我们要明白用户需求与产品需求的概念。用户需求是用户从自身角度出发，自以为的需求。用户经常提出的需求，从他们角度而言都是正确的，但更多是从自身情况考虑，对于产品的某个功能有自己的期望，但对产品定位、设计的依据等情况不了解，他们的建议也许并不是该功能的最好实现方式，也就不足以直接作为产品规划的直接依据。

　　作者在书中谈到一个非常形象的事例：一个马车夫会告诉你他的需求是需要更快的马，但是他不会告诉你，他需要四个轮子的汽车。绝大多数用户不会告诉公司“颠覆性的需求”，而是“维持性的需求”。而产品需求的定义是分析用户真实需求，并找到符合产品定位的解决方案。我理解的“推导”一词的意思仅仅是，在不完全听从客户需求而采取自我定位分析的方式来真正满足用户的需求。我知道我对它的理解远远不够，具体是怎么定位分析，具体怎么分析需求，有哪些具体的实践措施，所以我分享这个问题，希望读者和我交流讨论，一起学习。

第二章  个人技术和流程：

　　1."100%的代码覆盖率并不等同于100%的正确性！",那怎么才可以达到100%的正确性？

原文回顾：

　　第二章的“ 单元测试的独立性”P27页，“要注意，‘100%的代码覆盖率并不等同于100%的正确性！’”

引用说法：

　　在目前行业内的成熟方案有如下几个
　　　　1、代码评审。
　　　　2、单元测试
　　　　3、静态分析工具

　　还有几个手段在业界尝试中
　　　　1、结对编程
　　　　2、代码建模
　　　　3、编译分析

我的认识：

我是因为对推理过程有疑问而提出这个问题。从覆盖率到正确率，在专业解释下，我也有自己的认识。写代码注意结构和代码规范，注释要写全，代码尽量精简。代码覆盖率统计是用来发现没有被测试覆盖的代码，但是代码覆盖率统计不能完全用来衡量代码质量。“覆盖率”不是百分之百，但是可以让正确率尽量接近100%，要想实现这一想法，我觉得自己写一个程序实践之后会有更深的体会，但是我还是对覆盖率充满了困惑。值得一读博客¹，后期学习中，我会继续关注测试和覆盖率问题，希望发表一篇相关的简单易懂的博客。

第16章  IT行业的创新：

　　1.人生也是经历从出生，成长到成熟，最后再到衰老的阶段，如果用对待人生生命周期的态度来对待产品的生命周期，产品创新之前必要的措施是什么？

原文回顾：

　　第16章的“ 效能过剩和竞争的各个阶段”P362页，“一个产品在其生命周期有不同的阶段，每个阶段有不同的关注点，适时适当的功能点创新”。

引用说法：

　　

　　1.启动阶段：

　　　　找到用户痛点，做好功能分析，迅速上线验证，种子用户认可。

　　　采取方法或者步骤：

• 通过市场调研的方法找到用户痛点；
• 根据用户需求，做好需求分析；同时建立自媒体通道，为种子用户和后期运营打基础；
• 迅速完成原型，做好设计，快速开发，做好产品测试，保证用户体验；
• 获取种子用户，跟踪并做好意见反馈，做好数据分析，不断改进和提升产品体验，以获得种子用户的认可

　　

　　2.成长阶段：

　　　　获得用户，转化变现，建立品牌，名声远播。

　　可以采取这样的方法或者步骤：

• 利用前期积累的种子用户迅速推广，扩大影响力；
• 加强运营团队建设。主要围绕运营展开工作，一方面做好拉新，促活和留存工作；另一方面搞好品牌建设；
• 继续建设好官方自媒体通道，同时与外界媒体保持联系并搞好关系；
• 做好数据分析。用户方面要重点关注用户留存率，DAU（日活跃用户数量），MAU（月活跃用户数量），以及付费用户数据和ARPU（每用户平均收入）等数据；推广方面要重点关注推广渠道数据，根据数据优化渠道组合

　　3.成熟阶段

　　　　活跃并维系好老用户，同时保持新用户增长，继续稳定地实现创收盈利。

　　可以采取这样的方法或者步骤：

• 活跃并维系好老用户，主要利用运营手段，采取激励体制激活他们；
• 继续数据分析以及产品迭代工作；
• 继续做好用户转化变现工作，进一步提高营收能力。

　　4.衰落阶段:

　　　　尽力做好用户回流工作，同时更新产品线，寻求创新和转型，以求解决用户新的痛点，从而继续占领市场。

　　可以采取这样的方法或者步骤：

• 继续做好其他方面运营工作，数据分析方面重点关注回流率；
• 关注竞品的动态，做好竞品分析，借鉴竞品模式，提升产品竞争力，以求从竞品手中抢夺用户，或者不被抢走用户；
• 进行市场调研（包括竞品分析），寻求新的项目机会，或者更新产品线，想办法满足用户日益增长的新需求的目的。

　

　　总之，我们应该明确产品生命周期所处的阶段，并且利用产品的生命周期去有效的指导我们去开展产品方面的工作，以求最大程度地实现产品的商业目标和用户目标，实现创新的必要前提（参看博客²）！

我的认识：

我是因为对生命周期分阶段创新前提困惑而提出这个问题。我对生命周期各个阶段的的知识了解很少同时又对针对阶段的具体创新措施感兴趣，所以提出这个问题。目的决定一切！产品生命周期的每个阶段都是有其目标的，我们要想制定出针对各个阶段最有效的策略。这个整体目标就是：延长产品最大盈利的周期，提升产品的寿命，减缓衰退进程。对待软件生命周期和人的生命周期一样，减少衰退进程，提升价值。创新前的必要措施在“引用说法”部分很详实，我就不再赘述。既然前提已经满足，接下来的创新部分就有了一定的保障，也可以增创新过程中的自信力。所以我提出这个问题并且在乎具体的措施。

尾言：思成长之路，获理想灯塔

有幸了解到邹欣老师以及他的著作《构建之法》 ，我已经感受到未来这一学期我将获得巨大的收获，我会积累软件开发相关的知识，提升技术技能，对通用的软件设计思想和软件工程思想深入理解，尝试着将创新带入今后的团队合作中去，有效地实现团队管理和有效地实现团队的创新，希望自己可以在今后的团队合作中摸索出经验。我会用长足努力见证自己的成长历程，收获能量到达理想彼岸的灯塔！

1　　代码覆盖率常见的几种方式浅谈http://blog.csdn.net/qq_30953277/article/details/52174482

2　　产品生命周期的阶段，不同阶段的产品策略都有哪些http://www.91yunying.com/38334.html