读着读着《构建之法》(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%,要想实现这一想法,我觉得自己写一个程序实践之后会有更深的体会,但是我还是对覆盖率充满了困惑。值得一读博客1,后期学习中,我会继续关注测试和覆盖率问题,希望发表一篇相关的简单易懂的博客。

第16章  IT行业的创新:

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

原文回顾:

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

引用说法

  

  1.启动阶段:

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

   采取方法或者步骤:

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

  

  2.成长阶段:

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

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

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

  3.成熟阶段

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

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

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

  4.衰落阶段:

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

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

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

 

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

我的认识:

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

尾言:思成长之路,获理想灯塔

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

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

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

原文地址:https://www.cnblogs.com/weixq351/p/8592599.html

时间: 2024-10-07 10:58:53

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

读《现代软件工程--构建之法》1~5章的感受

1:看完书后的第一感觉: 晚上抽出时间看了软件工程这本书.刚开始的时候我也就凭着对作业的要求去看了1~5章,并没有深刻的去了解,甚至有的章节还就一眼带过,或者直接跳过,直到很随便的看完后,并没有了解到多少.说句心理话,这本书在我认为真的是很枯燥乏味,但能成为我们的学习课程之一,一定有它的好处,有它的知识值得我们去学习.之后带着想学知识的心理再重看了一遍,心里大概的了解到什么是软件工程,怎么有效的写出代码.若以后工作中,承当一个软件工程师的话,该如何做,才能在自己的工作团队中发挥到最有效的成果.

读《现代软件工程——构建之法》所获

在以前的学习当中,不明白软件工程是什么,能做什么,有什么特点,如何去做,以及IT行业的真正含义是,开发一个软件有哪些流程,目标等等这些疑问,在阅读<构建之法>之后,得到了一定的解答. 1.软件工程是什么? 软件工程是把系统的.有序的可量化的方法应用到软件的开发,运营和维护上的过程. 2.软件工作能做什么,有什么特点? 软件工程,学习和了解开发软件的一门课程,是软件开发的基础课程,从<构建之法>这本书中,学到如果要用软件工程做什么,必须付出更多的努力以及掌握更多的知识. 特点:复杂性

读《现代软件工程——构建之法》第1~5章有感

第一章的问题:在我了解第一章的时候,我比较着重于软件开发过程的难题,对于这5大难点的解决,我还是有点迷茫,我在想随着软件工具的开发是否会减轻这些难点,但是工具更多不是要求更高,对于一个团队密切不是需要更严密? 第二章:在关于单元测试和回归测试中,单元测试我们改如何具体描写,还有如果由单个人操作,那在temp的合作中该怎么分工. 第三章:在这章中,我想到一个局外问题,职业与证件,是否因为职业而采取证件措施,还是一个人能力依据证件表现? 第四章:在2人合作中,调试工作应该如何划分,最后调试为最主要,

读现代软件工程之构建之法的疑问

在第一章中主要讲的是软件的的发展,和软件工程的定义,以及软件工程各个方面的过程.在第一看完这章后确实有种冲动.但是在冲动后有种疑问.在软件的复杂性中写道,工程师在维护程序时最多只能看到30-80条代码,但是在上百万条代码的程序中,我们该怎么维护.以我为例,当我在做一些几百行小程序时,我想要返回来修改一些代码(这些代码是正确的,只是想改变功能),有时都摸不着头脑,都不知道,要修改的代码在哪一行. 在第二章主要注重的是个人能力的培养,也是进入一个软件设计团队的基本要求.在本章中,主要是在以程序的单元

读《现代软件工程——构建之法》第8~10章

真心看不懂! 第八章  需求分析  8.2软件产品的利益相关者  8.4功能定位 问题:怎样才能高效率的广泛而深入地了解用户的背景.心理.需求等等? 第九章 项目经理 问题:作为一个PM,如何能让自己得到所有团队人员的支持?作为一个PM又该如何管理好自己的同事,使项目做的更好?(感觉这一点是很重要但又好怕自己做不好的,毕竟每个人都有每个人自己的生活.) 第十章 典型用户和场景 问题:如何能更进一步深层次的挖掘用户的需求?

《构建之法》初读笔记

虽然当初决定考计算机研究生的时候就已经做好了要承受很大压力的心理准备,但是真正上课了还是有点吃不消,就像根本没想到会调剂到离家这么远的东师大,我也没想到研究生的课会刚开始就进行编程,跟本科就是计算机的同学比起来我编程的能力差的不是一点两点,这几天耗费了太多的时间导致没有太多时间读这本<构建之法>,在今天提交了作业以后才有空第一次接触这本书. 我本科并不是计算机,计算机相关的课程也几乎没学过,所以书里讲的很多概念对我来说都很新颖很有吸引力,更像一本引人入胜的小说,邹老师用很多生动的例子生动的表述

构建之法,运用之妙,存乎一心

构建之法,运用之妙,存乎一心:读邹欣<构建之法> 1. 构建之法,存乎一心 史学理论与史学史,是把历史自己作为研究对象的学科,前者讨论历史本身所研究的内容,后者讨论历史研究本身的历史.这种对于抽象的抽象的研究,正符合计算机领域 meta... 这样的思想.当年 xml 刚出来时,不少计算机和图书情报的大学生照本宣科地提到,xml是关于数据的数据,是 meta-data. 史学理论与史学史专家周老师在谈到史学理论的时候说到 (大意) ,学习史学理论与史学史,必先有历史的修养,要努力了解更多的史实

初识《现代软件工程——构建之法》

一.软件 1.软件概念 在学习软件工程这门课的时候,对于软件的概念还局限于软件=程序,程序就是软件,软件就是程序. 但是在这学期学习了软件工程这门课程后我知道了软件=程序+软件工程,软件不只是有程序组成的还有软件工程,这才是软件的组成结构. 软件的开发和发展是需要很多的条件的,像前期的策划(需求分析.市场价值等).后期的改进和营销等.这些都是决定一个软件的发展必要条件. 2.软件开发有四个阶段: 1.玩具阶段 2.业余爱好者阶段 3.探索阶段 4.成熟的产业阶段 3.软件的特殊性: 1.复杂性

初读《构建之法》(Build To Win)有感

最近略读了<构建之法>被作者诙谐幽默的写作风格深深吸引住了,文中有大量通俗易懂.形象鲜明的例子,更好的理解文中提出来的概念与理论.我是第一次接触到软件工程这门课,之前对于软件工程的理解就是编程写出一个应用程序,然而当我对读了本书之后,才对软件工程有了一个大概的了解. 在本书中,作者提出了一种全新的教学理念"Learning by Doing",也就是"做中学",与传统的教学方式不同的是提倡学生在大量的实践中学会知识.应用知识,掌握实用的软件工程技术.同时