M1/M2总结
M2阶段也快结束了，在此对M1和M2阶段做一份总结。
之前的问题
之前在http://www.cnblogs.com/encoin/p/4027044.html中提出了5个问题，现在去看觉得当初提的问题挺幼稚的。而且自己也给出了回答，在此就不再赘述，仅对最后一个问题做一些补充。
对于最后一个问题，我之前的答案是先多了解几门，然后选择自己感兴趣的。经过这学期的学习，我觉得我也不知道自己到底对什么语言最感兴趣，感觉就是这一段时间用什么语言写多了，写惯了，似乎就偏向于那种语言了。只是很多时候会因为需求的不同，你可能会被要求要学习一门新语言或者使用的根本不熟的语言，最开始时我是比较抓狂的，后来如果习惯了，用熟了，后来的语言就会取代之前常用的语言。总结下来，这是一个变化的过程。另外，不同的语言是适合不同场景的，用C去写个网站是很难想象的。
新的问题
M1、M2阶段相较于之前的个人项目和结对项目，时间跨度是很长的。在这段时间内，不仅仅是要完成这个软件项目，而且还有其他的事情，时间的分配是需要权衡的。如果是短时间内要完成可能就会集中到一个时间段内逼着自己做完，但对于一个工程量大的项目而言，短时间赶完显然不科学且不现实。更何况这是一个团队的项目，每个人有每个人的事情，成员A的任务没及时完成还会影响成员B。所以一个新的问题就是对于这样时间跨度相对较长，人员涉及多的项目，时间应该如何分配？每天？定时？动态？
关于软件工程文章
之前阅读过几篇软件工程方面的文章，写了一些笔记：
http://www.cnblogs.com/encoin/p/4091826.html
http://www.cnblogs.com/encoin/p/4085706.html
http://www.cnblogs.com/encoin/p/4081014.html
经过了M1/M2阶段，新的体会...以需求为驱动，软件工程方法论的运用这些方面吧，但还是有些模糊，文章里的理论自然是对的，但是哪怕经过了团队项目的开发，感觉我们的实际经验也远远不足。
知识点
需求阶段
竞争性需求分析框架 NABCD模型
1) N (Need 需求)
你的创意解决了用户的什么需求?
我们要充分了解用户的痛苦, 他们对已有软件, 服务不满意的地方。但是用户往
往也不知道颠覆型的创新
2) A (Approach 做法)
你有什么招数, 特别是独特的招数, 来解决用户的痛苦。
这些招数不光是技术上的, 也可以是商业模式上的, 地域的, 人脉的, 行业的.
3) B (Benefit 好处)
那你这个产品/服务会给客户/用户带来什么好处呢?
Benefit/Cost (成本) 的问题。
4) C (Competitors 竞争)
竞争对手也没有闲着, 这个市场有多大, 目前有多少竞争者在瓜分, 你了解么? 你
如果不是最先进入某个市场的产品, 你还能赢么?
5)D (Delivery 推广)
设计阶段
Spec = Specification /规格说明书
Functional Spec
Tell people about a feature/function of a product,
From user’s perspective
It doesn't care how the thing is implemented. It talks
about features. It specifies screens, menus, dialogs,
and so on.
Technical Spec (aka design doc)
Tell the software team member or other partners how
the function is implemented
data structures, relational database models, choice of
programming languages and tools, algorithms, etc.
实现阶段
SCRUM is an iterative, incrementalmethodology for project management often seen in agile software development.
Roles
the “ScrumMaster”, who maintains the processes
(project manager)
the “Product Owner”, who represents the
stakeholders and the business
the “Team”, a cross‐functional group carrying out the
actual analysis, design, implementation, testing, etc.
测试阶段
测试要找出BUG
Bug has 3 aspects：
症状（Symptom）
程序错误（Fault）
根本原因（Root cause）
Symptom：即从用户的角度看，软件出了什么问题。
▪ 例如，在输入（3 2 1 1）的时候，程序错误退出。
Fault：从代码的角度看，代码的什么错误导致了软
件的问题。
▪ 例如，代码在输入为（3 2 1 1 ）情况下访问了非法的内存地址—
—0X0000000C。
Root Cause：错误根源，即导致代码错误的根本原
因。
▪ 例如，代码对于id1==id2的情况没有做正确判断，从而引用了未
赋初值的变量，产生了以上的情况。
发布阶段
关于发布说明
发布说明主要描述系统已知的问题和限制。例如：
对运行环境的要求；
对安装方法的要求；
用户要提供的信息；
描述系统已知的问题和限制；
系统的版权声明，
系统的售后支持，
联系方式。
维护阶段
发布之后，进行维护。根据用户的反馈等进行改进。
验证产品质量
所有以前的bug都重新验证过之后，我们就可以
用当前的版本作为发布版本。
