1、在像我一样没有什么基础的人要怎么学习好构建之法？
这本书让我更加认识到实践的重要性，要从做中学。只有实践了才能够真正发现自己的不理解的知识，还能够促进学习的效率。这个学期我自己写代码，做火车订票系统，以前认为学会的知识，一开始做的时候，感觉实践应用和己看书理解有出入。以前认为这样做是对的，现在感觉那样做更简单，减少代码量。比如通用函数的封装，以前感觉没有必要，现在自己写代码的时候，感觉封装能大大简化代码。
2、软件的需求分析我们应该从哪方面具体分析？
软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化，分析各种可能的解法，并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求
3、很重要的团队合作我们要怎么做起？并且书中提到‘敏捷的团队‘要怎么实现？
敏捷开发以用户的uandui需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
4、学习完构建之法，怎么应用软件工程这门课来为我服务？
《构建之法：现代软件工程》，感觉对于软件工程这门课程不再那么的空洞，作者把软件开发方法讲得清晰有趣实用，对于许多对软件开发有兴趣的同学，又燃起了更大的兴趣与热情。不再是软件工程所讨论的代码量巨大，涉及人数众多，项目需求多变，抛开软件工程也能完成，甚至更快捷。绝大部分软件都是由多人合作完成的，大家的工作相互有依赖关系。软件的很多错误是来源于程序员对模块功能的误解，疏忽或者不了解模块的变化。单元测试就是一个有效的解决方案。软件开发流程不只是团队的流程，还包括个人开发流程。在软件工程的语境里，“敏捷流程”是一系列价值观和方法论的集合。从2001年开始，一些软件界的专家开始倡导“敏捷”的价值观和流程。人们为了解决现实社会和生活中的各种问题，要求助于软件。软件团队需要找到软件的利益相关者，了解和挖掘他们对软件的需求，不同的项目需要不同的手段。《构建之法：现代软件工程》是理论和实践相结合。讲现代理论，同时讲体现理论的工具。
5、团队之中如果有拖后腿的人要怎么办？
在一个团队里面总有那么一个人会不跟着团队的脚走的 所以正视一下这个现象就好 要想解决这个问题的话 首先要了解这个人是因为什么原因老是拖团队的后腿 是因为个人能力问题还是因为个人的不配合 如果是个人的能力问题的话 那么你可以分配给他一些他力所能及的事情让他做 如果是因为个人态度问题的话 你可以和他好好聊聊 如果他实要不想做的话 你可以换人了
6、以往的项目开发有什么经验以及建议？
7、对学好软件工程有什么建议？
尽量让自己多了解一些现实中的软件开发过程，或者参与到一些简单的软件开发中，了解人们的方法与问题后，再与软件工程中的理论相比较，你就会有意想不到的收获！软件工程的更高层次，会和其它管理学科一亲友，回归到哲学和人性本身上面来。不过这个高度需要时间和实践的。
软件工程心得体会未接触软件工程之前一直都很想学这门课程，因为觉得这门课很牛，是那些有工程师称号的高手才摆弄的东西。学了一个学期的软件工程课，终于知道了个软件工程的大概。学的时候总觉得很抽象，理解起来好像不难，但总是摸不着头脑一种很茫然的感觉。曾经以为程序就是软件，软件就是程序。学习这门课程第一个收获是，知道了二者的不同之处。以前做过的一些小型的软件比如加密软件，我也只是在程序旁边附上一个软件的说明，看来已经很接近作坊了。不过大的项目没有接触过，用软件工程的方法还是第一次。我想也是程序的不断复杂化导致了软件危机的发生，使得人们不得不探索新的解决方法。
经过冯老师的讲解，理解了软件工程，就是一套用于软件的团队开发，以提高软件质量和程序员工作效率为目的的规范。其核心就是，对于软件开发的5个重要组成部分：需求分析，设计，编码，调试，维护，如何组织这5个部分的工作，以及如何完成每一个工作。吾生也有涯，而知也无涯，学习永无止境。起初，对软件工程处于一知半解的状态，分工比较混乱。
在划分模块后明确了各自分工，渐渐形成良性循环。在学习过程中，知道了团队合作十分重要，争议固然存在，但通过讨论、协商，群策群力，在不断磨合中能够达成一致与默契。团队成员中能力各有高下，互相尊重，各取所长，不宜妄自菲薄。组长多加协调，组员积极配合，才能合作愉快。学习能力体现在能尽快接受新的知识，顺应变化，学为所用。
上《软件工程》这门课，我的收获大概如下：我们为什么需要软件工程呢？上面已经给出了一些原因。专业点讲，软件工程最终是为了实现“软件制造业”的社会化,工业化大生产,提高其劳动生产效率。只有如此,软件业才能实现社会化,工业化大生产,才能“做大做强”。没有管理的设计是失败和混乱的设计，没有设计指导的编程是无序的忙碌的。根据开发的软件的规模，应该适当程度的运用软件工程化的思想，需要灵活，毕竟我们开发的软件大多数是中小型的，大型的并不多见（我是这么认为的）。但只要涉及人员间的交流和沟通，或多或少都要需要软件工程才能更有效率，工作成果更稳定。
其实开发软件，就像是解决一个逻辑问题。想想自己平时是怎样写程序的。首先是要有一个想法，即我写的这个程序是要干什么的；然后就是对要实现的核心功能大概构思一种或多种实现方法，并从中选出一种自认为是较好的；接下来就是将涉及的各种主要或次要功能分成各个模块；最后就是分模块来编码和DEBUG。在我看来，除了第一步外，其余的步骤应该是一个循环的过程。在编码的过程中，你总是需要不断地回过头来修改原先的模块设计，甚至最初选定的实现算法。具体到每一步的工作要怎样完成，是非常灵活的，只要把握住大体的方向就行。在进行分析，设计，编码，调试，维护这几部分的工作的时候，最核心的就是文档的编写。1.可行性分析就是关于当前项目能不能干的分析结果。
2.项目描述这是在决定立项以后，对当前项目的一份扼要说明。
3.需求分析就是对客户要求的功能的定义。
4.软件设计这就是对程序的每一个模块的详细设计的说明文档。
5.开发日志我一直都认为这是文档中最有趣的部分。开发日志相当于编码阶段的文档，它的形式可以很随意，主要是记录一些在写程序时突然萌发的灵感，或对代码的一些微小的修改，或对程序结构的一些微小变动等，还要对上述这些修改变动作些说明。
6.测试分析用于指出程序存在或潜在的缺陷和错误，以及程序性能的数字描述