需求分析,是软件工程开发的第一步,准确全面地找到用户的需求,尽可能满足用户的要求,是软件惺惺发展的基础.所以需求分析很重要.具体来说有以下几个步骤: 1.获取和引导需求:软件团队需要找到软件的利益相关者,了解和挖掘他们对软件的需求,引导他们表达出真实的需求.不同的项目需要不同的手段,这一步骤也被叫做“需求捕捉”,形容真正的需求稍纵即逝,需要靠火眼金睛和敏捷的身手来发现并抓住它们.另外,有些用户并不知道自己确切的需求,或者不愿意表达完整的需求,这时候软件团队需要替用户着想,引导出需求. 2.分析和…

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

这段时间我阅读了<构建之法>的大部分章节,包括个人技能.软件测试.用户体验和需求分析等相关内容.之前的个人作业和结对作业结束后,我们的工作重心终于转向了团队项目,作为团队中前端组的组长,我和组员们每周碰面.共同商讨团队项目细节并一起实现.因此,书中与团队项目开发有关的第五章.第六章的“团队和流程”“敏捷开发”两部分内容最令我印象深刻.受益匪浅,本次读书笔记主要记录阅读这两章的心得体会. 1.团队模式和开发流程: 团队项目的开发与团队工作模式(分工模式)和整体开发流程息息相关.我们的团队在决定开…

1.书中第4章4.5节所说的结对编程让我感觉有一点困惑,书中书写的是结对编程,说实话我是第一次接触这个词汇,我能感到这种方式的新特之处,但是对比我现实的编程经历,我很难想象在一般的企业开发中这样的行为能否能顺利展开,可以想象这样一个场景,比如说我们开发基于hadoop的一个小系统,突然忘记一些简单的命令是常态,这时候不免会去查一些简单的资料.如果我们采用结对编程的模式,尴尬的事情就会发生了,一起的队友是否会觉得你能力不足,又或者即使能找到技术匹配的队友,这时候也很难说他们的性格相符,而且在中国传…

第七章 MSF MSF基本原则 推动信息共享与沟通 为共同的远景而工作 充分授权和信任 各司其职,对项目共同负责 交付增量的价值 保持敏捷,预期和适应变化 投资质量 学习所有的经验 与顾客合作 MSF团队模型 MSF团队模型定义了小组同级成员的一些角色和职责,在MSF团队模型中,任何技术项目都必须达到特定的关键质量目标,才能够被认为是成功的项目.任何一个角色无法实现其目标,都将危及整个项目.因此,每个角色都被认为是同等重要的,重要的决定都要共同做出.一个项目要达到的目标很多,MSF团队模型让不同…

本周选读<构建之法>第8章——需求分析.由于有团队项目初期调研阶段做调查问卷的经历,这一章节中很多知识点我都比较有体会.对我而言,这一章节最有价值的内容就是厘清了关于需求分析的两个误解和近10个行之有效的调研方法. 第一个误解有关需求的内涵.需求不仅仅来源于用户(软件直接使用者)的需要,还可以是企业为维持生存.追逐利润的商业模式,或者开发者在考虑到代码迁移.架构演化.平台变化时提出的技术上的需求.另一个误解有关需求分析的实现.做需求分析是一个循序渐进.应时而变的过程,不只是简单地将用户所表达的…

软工读书笔记  week 9                 ——<构建之法> 最近的三周我们正式开始我们的项目.然后我也把<构建之法>中的相关章节再拿出来读了一番.以下是一些感悟. 首先就是第十章“典型用户和场景”.书中提到,我们作为设计或者开发者,往往会以自己使用产品的习惯和熟悉程度来出发设计,但我们永远不能代表用户.搞一个“典型用户”会让我们考虑问题从用户的角度出发.由于我们正式开始项目后的第一周就是继续对用户做需求分析,这一章对我们有很大帮助. 我们也要考虑我们的典型用户.…

本周主要对<构建之法>中的一部分进行阅读. 一.软件与软件工程究竟是什么? 本书的概论部分就指出“软件 = 程序 + 软件工程”.而我们这门课的名字就叫“现代软件工程”.其实在上课之前,我对这门课存在一定的误解,我更多地把这门课归入“程序”部分.在我原来的理解中,像电设二一样,自己学新知识(当然很多在电设一已经学过),然好以团队的形式独立去完成一个项目,只不过电设属于硬件(也包含一部分软件),而软工则纯粹是软件了. 而上课之后却和我预想的不一样.首先每周读书笔记这个就让我非常不解,有些推荐书籍…

阅读完了<构建之法>第一章后,觉得我们平时使用的软件并不是自己想象中的那样简单,用的时候是觉得很方便,但从来没有考虑过一个软件的背后需要一个团队多少的付出才能换来一个获得用户频频好评的软件.突然之间很佩服所有软件的开发者,因为在读了概述之后,我就能体会到他们背后付出的努力.时间和精力. 软件=程序+软件工程.要有一个软件,首先需要一个程序,而算法.数据结构是程序的基本功.其次软件工程的核心部分是:构建管理.源代码管理.软件设计.软件测试.项目管理等相关内容,软件工程直接决定了软件的质量.在现在…

总时长近两周的结对项目终于算是结束了,马上要重新开启团队项目.于是这几天决定对<构建之法>一书中与团队项目及需求分析有关的章节进行重点阅读,希望能够从中得到启发,并运用到接下来的团队项目中去.        团队模式 团队这一部分提到了软件团队的很多模式.我认为,就我们目前的团队项目而言,更合适的应该还是“交响乐团模式”和“功能团队模式”. 先说“交响乐团模式”(吐槽一下书上给交响乐团配的图真是错误百出,当然这不是重点,只是觉得应该还是要严谨一些),我自认对一个乐团还是非常了解,在一个乐团中,…