阅读《构建之法》八九十章

    第一次阅读构建之法,把以前很多门课的知识点联系到了一起.      软件=程序+软件工程.我认为这是对软件的一种及其精炼的解释.程序即是指一行行代码,软件工程则包含了各种软件开发活动,包括构建管理.源代码管理.软件设计.软件测试.项目管理等等,是把系统的.有序的.可量化的方法应用到软件的开发.运营和维护上的过程.      从一个简单的程序,扩展到一个满足各种功能的应用软件,再扩展到一个能保证服务质量的软件服务.源程序是建立在数据结构上的一些算法.构建不仅仅是CC和link命令,一个复杂

今天阅读了构建之法第一章,感觉到自己其实玩具的阶段都不到,离研究阶段更是差的有段距离.了解到程序其实只是一个藏在你电脑里的数据结构加算法,要想成为软件还得经历软件工程这一阶段,软件工程便是把系统的.有序的,可量化的方法应用到软件开发,运营和维护上的过程中.首先我要进行软件需求分析,一个成功的软件是要有市场需求作为背景的,没有需求你做的软件就是无用的东西,有了需求然后我们对软件进行设计使之安全 可行 基本满足市场的需求.然后我们便对我们的软件进行测试.最后软件在用户手中运行,但是十全十美的软件是不

1.为什么选择计算机这个专业; 当初读本科的时候,一志愿填的是电气工程及其自动化,估计是因为分数太低了被调剂到了网络工程专业.之前的我并没有过多的接触计算机,感觉自己对这方面并没有多大的兴趣,本科的时候自己的学习并没有多么的认真.当时自己还想过要转专业,后来也不了了之了.慢慢的感觉这个专业还可以,也就学了三年,后来到了考研的时候,本来打算考金融专业的,但是跨专业考研难度挺大的,而且最近几年计算机这个专业实在是太火了,毕业之后工作找工作各方面都不错然后就限定决心考了计算机技术.庆幸的是考上了,现在

今天读了<构建之法>的第15章:稳定和发布阶段 Alpha:指集成了主要功能的第一个试用版本. Beat:功能基本完备,稳定性较Alpha版本高,用户可以在实际工作中小范围使用. ZBB:某天的版本把在之前记录的Bug都解决掉 RC:发布候选版本 RTM:最终发布版本 RTW:和RTM类似 会诊小组 软件团队的各个角色代表组成了会诊小组,处理每一个影响产品发布的问题. 决定对每一个Bug采取以下哪一种行动: 1.修复 2.设计本来如此 3.不修复 4.推迟 复杂项目的会诊 第一步:开发者提交惨

<构建之法>第10.11.12章 第10章: 问题:对我们了解了用户的需求后,但是我们想法和做出来的软件会和用户的需求有偏差,比如风格.界面的修饰等等,那么我们程序猿怎样才能让自己的想法更加靠近用户的想法呢?是设身处境么? 第11章: 问题:我们现在这个阶段是在做四则运算APP,如果按照这章的步骤走下去,每天都要进行进度更新,和每日会议还有每日构建的,会不会不太符合我们现在的处境?毕竟我们的所有时间不能只为一门课程服务,还要大量的时间花在其他的课程上呢. 第12章: 问题:在实际的项目中,我们

第十章: 典型用户和场景对后面工作有什么帮助吗? 第十一章: 每日构建的目的是什么呢?有没有具体说明? 第十二章: 产品定位人群是否也局限了产品的可拓展性?

第十章典型用户和场景 1.典型场景和典型用户 对用户的认识,例如用户的价值,如何定义用户,用户与场景的结合,在从场景到任务等,还有用户的模板或者故事. 2.规格说明书 (1)功能说明书 定义相关的概念->规范好假设->避免误解,界定一些便界条件->描述主流的用户/软件交互步骤->一些好的功能和副作用->服务质量 (2)功能说明书模板 (3)技术说明书 (4)功能驱动的设计 构建总体模型->构建功能列表->制定开发计划->功能设计阶段->实现具体功能 对

第十章(P183  10.1) 问题:用户的真实需求是什么?我们要如何理解用户的真实需求? 第十一章(P203) 问题:如何跟客户交流,避免误解? 第十二章(P230) 问题:用户体验设计该从哪方面着手?有哪些步骤?

第十章讲的是关于典型用户和场景的内容. 在第一节当中,为我们介绍了Visual Studio的典型用户.典型用户的价值.怎样定义典型用户还有从典型用户到场景到任务的转变,还简单介绍了场景故事story的模板: 在第二节当中,为我们介绍了用例(Use Case),用例的基本元素包括标题.角色.主要成功场景.步骤和扩展场景: 在第三节当中,为我们介绍了规格说明书(Spec),它可以分为两种:软件功能说明书(Function Spec)和软件技术说明书(Technical Spec): 在第四节当中,