软件工程网络15个人作业4（201521123010徐璐琳）——alpha阶段个人总结
一、个人总结
1. 总结自己的alpha 过程:
经过了两周的ALPHA阶段，在这之中学习到了很多，因为最开始其实是有抱着一种应付的、将就着的心理去做这个小程序，但是在完成项目的过程中，有老师和助教一直在鞭策和鼓励我们，心理状态也在慢慢地改变，从被动变成了主动，也在这个过程中，知道了一套完整体系的工程具体有什么元素，不单单是几页代码就完事的。此外，因为我们做的是微信小程序，也是第一次接触JAVASCRIPT和WEB，和之前课设不同，这一次是边学边做，所以在短短两周内只能逼自己去学习更多。但好在是一个团队，大家共同分担，一起进步。
2. 自我评价表：
二、回答问题
徐璐琳的个人阅读作业2
问题一：读P8时，1.2软件工程是什么？
软件工程的思想目的和其他学科的工程方法（比如土木工程等）并无太大差异，主要是降低软件系统的复杂性、提高其可控性，以此在软件开发、维护、测试等各个阶段提高效率。软件工程体系包含为完成软件需求、设计、构建、测试和维护所需的知识、方法和工具。也在这段时间认识到了，软件工程不局限在理论之上，更重要在实践上，能够帮助软件组织协调团队、运用有限的资源，遵守已定义的规范，通过一系列可复用的、有效的方法，在规定的时间内达到预先设定的目标。针对软件工程的实施，无论是采用什么样的方法和工具，先进的软件工程思想始终是最重要的。只有在正确的工程思想指导下，才能制定正确的技术路线，才能正确地运用方法和工具达到软件工程或项目管理的既定目标。
问题二：P31对于两种效能分析方法的具体使用？
这两种方法是抽样、代码注入。
抽样就是当程序运行时，VS是不是看看这个程序运行在哪个函数内，并记录下来。等到程序结束后，VS就会得出一个关于程序运行时间分布的大致印象。
代码注入就是将监测的代码加入到每一个函数中，这样程序的一举一动都被记录都在案，程序的各个效能数据都可以被精准地测量。
一般的做法是，先用抽样的方法找到效能瓶颈所在，然后对特定的模块用代码注入方法进行详细分析。
问题三：P121敏捷流程中的第三步半问题？
之前是搞不懂敏捷流程为什么一定要设置第三步半这一步骤，后面又查阅书籍资料后了解到：做过项目的人都知道，当你说“任务都完成了”的时候，那只是说，开发人员认为该写的代码都写完了，但其实还有很多事情没做完。例如写一个Windows客户端的功能，显示一张新闻图片，加上与它相匹配的文字（假设这些图片/文字都可以从互联网上拿到），做完之后，还有下面的事情。我们感觉好像项目完成了80%，殊不知后面的20%往往要花费80%的时间，敏捷流程没有明确表明到底何人何时以何种优先级来完成这20%的任务。而这第三步半就设置了测试，测试人员在这个冲刺中也起到了很重要的作用。
问题四：敏捷流程到底实质上是什么？
敏捷开发流程实际上是一种以人为核心、逐步迭代、循序渐进的开发方法。敏捷思维不仅仅可以用在开发，其实各个行业，各个岗位都可以用到，它注重的是人与人之间，面对面的交流，而不是瀑布型的文档驱动，不能没有文档，但是不用写大量的文档，重点写必要的文档。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
问题五：P168的关于竞争性需求分析？
NABCD竞争性需求分析，是我目前在软件工程中接触最多也最深刻的内容。“NABCD”是由Need、Approach、Benfit、Competitors、Delivery五个单词的首字母组成，分别指需求、做法、好处、竞争、推广五部分。通过这五部分，可以清楚简明的把项目的特点概括出来。而在我们项目中，对于这五项需求的分析十分重要，在写NABCD模型时其实我对项目中的一些地方还有疑惑和疏忽。一边查阅一边写完了NABCD之后又有了更好的思路提供，怎么样做才对项目更有利。自己还尝试做了和书上饼图类似的模型，一眼明了。
三、再提问题
同时，大家一定会在实践过程中产生更多问题， 结合你的读书（教材，博客，参考书）， 实践， 再提出关于软件工程的 5 个问题。
1. 在每个问题后面，请说明哪一章节的什么内容引起了你的提问，提供一些上下文。
2. 列出一些事例或资料，支持你的提问 。
3. 说说你提问题的原因，你说因为自己的假设和书中的不同而提问，还是不懂书中的术语，还是对推理过程有疑问，还是书中的描述和你的经验（直接经验或间接经验）矛盾？
问题一：单元测试的标准评判是？
我看了P25-P28这几页文字，想提出问题：我已经知道了单元测试的9个评判标准，可是什么程度才算是好的单元测试呢？
查了资料后，发现对于好的标准也没有具体定义，而倒是更明确了单元测试的意义，知道了当代码通过编译时，只是说明了它的语法正确；我们却无法保证它的语义也一定正确，此时单元测试会为我们的承诺做保证。编写单元测试就是用来验证这段代码的行为是否与我们期望的一致。有了单元测试，我们可以自信的交付自己的代码，而没有任何的后顾之忧。但对于这个好的标准定义，我还是不太懂。
问题二：完整的代码规范？
这是个老生长谈的话题，要解决前面说的这些情况，必须要有一个规范来进行约束。不以规矩不成方圆。这其实是自己的问题，因为在之前ALPHA阶段时我们团队每天都要检查修改并上传代码规范，但我们的代码规范也仅限于对于参数的定义、格式的定义。而我查阅网上资料时发现有的代码规范十分完整，像一套完整的体系一样，对于类的定义、函数生命周期、变量参数等都有解释说明。所以我也不太清楚完整的代码规范到底要包含哪些内容，还是说只要是能让团队的成员一眼就能清楚的代码规范就足够？
问题三：怎么选择适合自己团队的开发流程模式？
软件开发流程即软件设计思路和方法的一般过程，包括对软件先进行需求分析，设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编码和调试、程序联调和测试以及编写、提交程序等一系列操作以满足客户的需求并且解决客户的问题，如果有更高需求，还需要对软件进行维护、升级处理，报废处理。而其中包含了边做边改模型、瀑布模型、演化模型、增量模型、螺旋模型、喷泉模型、敏捷模型-SCRUM，每个模型都有自己的优势劣势，那么应该从什么角度去选择适合自己的团队的开发流程模式呢？
其实在查阅资料后，我个人是偏向于迭代模型，迭代模型主张采用能显著减少风险。其可以：①加快整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。②降低在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。③降低产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。④由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。
问题四：关于用户调研---获取用户需求？
我看了书上P160-P168这几页文字，其中书上有这样写：“软件的功能和用户想要的一样么？不大一样。用户满意吗？不大满意，那用户到底想要啥？我们调研一下，然后开始新的循环。。。。。。如何准确掌握用户需求？”个人认为这个问题直戳中了很多开发团队的心理，对于一个开发团队来说，自己开发出来的软件到底是不是用户所需是十分重要的。书上也说明了集中常用的用户调研方法：①焦点小组：找到一群目标用户的代表，机上项目的利益相关者来讨论用户想要什么，用户对软件的评价等；②深入面谈：通过详细的面谈，广泛而深入地了解用户的背景、心理、需求等，通常是一对一的采访；③卡片分类：在收集反馈时利用“卡片分类”的方法，把各种需求做成便于规整的小卡片，然后反复进行讨论归类流程；④用户调查问卷：向用户提供实现设计好的问题，让用户回答（我们团队这一次也是采用调查问卷的方式，虽然会比较简单，但是感觉目标不够明确）；还有一些比较少用到的方法不做介绍。用户调研的方法看起来很多，但是大家都在围绕着同一个中心去获取用户需求。关于这个问题的提问，感觉是比较长久性的，我们一直在完善的目的也是因为要满足大多数不同用户的需求，所以对该如何最大限度获取用户需求这一点较困惑。
我查阅资料发现有几点原则十分重要：①没有一种人叫做“所有人”，了解需求的前提是细分用户。②和用户直接联系，而不是通过别人中转。③听用户的，但一定得自己做决定。用户描述的是需要，并不是需求，用户最内心的动机才叫做“需求”。④找到典型用户，并让自己变成自己产品的重度用户。⑤除了功能需求，了解用户背后的情感需求。
问题五：关于软件项目管理？
在ALPHA阶段的展示博客中，有个问题是“团队是如何进行项目管理的？"，当时我在写这个问题的时候，就有了疑惑，因为自己对于项目管理没有一个明确的定义，也不知道其的具体流程，所以回答得很牵强。既然是软件项目管理，那就先看什么是软件？什么是项目？什么是管理？我是这样理解的：软件是程序，是控制硬件功能并指挥其运行的程序、代码和符号语言；项目是具有明确的起止时间，明确的目标、范围和成本的一次性的工作；管理是将一些理论知识、技能、工具和技巧应用到项目活动中去的行为或艺术。那么软件项目管理就应该是：主要专注于软件项目活动的一些行为分析与管理。问题来了，那么在软件项目管理中我们该进行一些什么活动呢？
我认为一个项目管理需要考虑的远不止我们想象的那么多，往往需要在众多的、甚至是相互冲突的要求中寻求一种平衡，以达到满足每个团体各方面的利益：范围、时间、成本和质量，有不同需求和期望的项目涉及人员，明确表示出来的要求（需求）和未明确表达的要求（期望）。那么上网查阅了资料后，发现软件项目管理可以分为几个阶段进行：①项目启动阶段；②项目规划阶段；③项目执行阶段；④项目控制阶段；⑤项目收尾阶段。而这几个阶段内要做的内容网上资料各有说法，虽然有个大概的框架，但是还是不能得到一套明确的答案。
4. 【附加题】：请将问题提交至豆瓣：https://book.douban.com/subject/27069503/， 并在博客中给出链接
在豆瓣页面的最下方 “读书笔记” 那里发言， 《构建之法》的作者会亲自答复问题
