第八章 这一章主要讲的是需求分析,主要介绍在客户需求五花八门的情况下,软件团队如何才能准确而全面地找到这些需求. 第九章 问题:我们现在怎样培养才能成为一名合格的PM呢? 第十章 问题:如果典型用户吴小石头的需求和问题太过麻烦或者复杂,我们是应该想办法解决还是换一个典型用户?…

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

第10章:典型用户和场景 阅读了第10章之后,我知道典型用户很重要,典型用户是某类群体的代表,他们的观点能够反映一类人的观点与对产品的要求,那么要怎么样才能够从一类群体里,选择正确的典型用户反映我们研发的软件的需求呢?在功能说明书里,假如我们现在还不具备某些技术,研发时间又短,我们还要把这些技术上的功能写进规格说明书与技术说明书吗? 第11章:软件的设计与实现问题出处:11.1.2开发人员的标准工作流程.从205页的流程图可以看出,要实现这个工作流程需要非常多的工作量,但是,想我们这样由几个学生…

身在大学,却想起了在高中的生活和初中的生活,特别是初中的生活,为什么这么说呢!因为<构建之法>,看了其中的两章的内容,为什么想到了初中和高中的生活呢,因为在高中和初三的时候看的最多的就是课本,虽然有时会看不进去,但是同样会硬着头皮去看,因为要想考一个好的高中所以就认真的学习,看书.但是到了大学,可以说很少去看课本了,都开始看电子版的书了,当然看的电子版的书,就分好坏了,(其实书都分好坏,主要是看你怎么去看待它,在书中看到的是什么,是主人公的坚持不懈的努力,还是一些其他的东西!)而我就看了好几本…

第八章——主要介绍软件需求. 主要步骤:1.获取和引导需求.2.分析和定义需求.3.验证需求.4.在软件产品的生命周期中管理需求. 对软件需求的划分:1.对产品功能性的需求.2.对产品开发过程的需求.3.非功能性需求.4.综合需求. 获取用户需求——用户调查 常用调研方法:焦点小组(Focus Group),深入面谈(In-depth Interview),卡片分类(Card Sorting),用户调查问卷(User Survey),用户日志研究(User Diary Study),民族志/人类…

第十章 典型用户和场景 问题:如何更准确知道用户的需求是什么,设计出满足用户的软件? 第十一章 软件设计与实现 问题:软件设计过程中,如何管理设计变更? 第十二章 用户体验 问题:在何时开始设计用户体验会更好?…

第六章-敏捷流程 第六章主要详细介绍了敏捷流程,在软件工程范畴里,“敏捷流程”是一系列价值观和方法论的集合.这一章以敏捷流程的Scrum方法论而展开,而敏捷流程的精髓就是在于快速的交付. 敏捷开发的流程如下: 1.找出完成产品需要做的事情 - Product Backlog. 2.决定当前的冲刺(Sprint)需要解决的事情--Sprint Backlog. 3.冲刺(Sprint).在冲刺阶段,外部人士不能直接打扰团队成员.期间每日例会,向同伴报告进度,把问题摆在明面上.同时启动每日构建,让大…

第一章 看了第一章,第一章主要是概论,主要讲述软件是什么,是由什么组成的,然后接着陈述软件工程是什么,看了第一章之后,得知,软件工程只是实现软件的一个工具,有了工具做事情才容易.还有进行运维和维护软件,并且我们所开发的软件要符合客户的要求,不能盲目开发,浪费精力和体力,根据自己的想法去做满足客户的软件,而且要不断的发现bug并进行修复.    软件工程在社会发展处于什么地位,发展潜力在未来究竟有多大? 第二章 看完第二章之后,我才知道之前我们的想法是多么的幼稚,以为可以运行就可以,才知道软件是需…

第四章 两人合作   这一章是讲述了两人结对编程的一些东西,包括一些代码的规范,还有结对编程的优点.怎么做.以及一些注意事项. 1.“错误处理 当程序的主要功能实现后,一些程序员会乐观地估计只需要另外20%的时间,给代码加一些错误处理就大功告成了,但是这20%的工作往往需要全部项目80%的时间.” 疑问:“错误处理”是什么概念?它有哪些类型及方法? 思考:我查阅了一下资料,上面解释道“在程序设计过程中,由于某些错误的存在,致使程序无法正常运行,处理这些错误以使程序正确运行就称为错误处理.”根据错…

<构建之法>第五章用体育运动等团队例子引出软件开发团队的形式,用更加生活化.形象化的例子让读者更能理解软件开发团队的形式.软件团队形式多样,适用于不同的人员与需求.团队可能会演变的模式有:主治医师模式.明星模式.社区模式.业余剧团模式.秘密团队.特工团队.交响乐团模式.爵士乐模式.功能团队模式.官僚模式等.开发流程模式有:瀑布模式.瀑布模型的各种变形.统一流程.老板驱动的流程.渐进交付的流程等.瀑布模式:当软件行业还在年幼的时期,它从别的成熟行业借用了不少经验和模型.在那些“硬”的行业中,产品…