软件工程-个人作业-提问回顾与个人总结

对曾经的问题进行解答

曾经问题的链接

回答

1. 我仍然支持之前的看法。作者提出的例子只能说明隐喻有助于进行软件开发，而不足以证明与“隐喻在帮助人们更好地理解软件开发问题方面所做的贡献，它帮助人们更好地理解科学问题所做的贡献一样大”这一观点。
2. 在我实际参与结对编程后，发现如果两人都同时关注驾驶员和领航员的任务，时间和精力是完全不够的，并且会有很多的分歧难以解决，因此我提出的领航员和驾驶员共同承担的想法理论上很好，但实际很难运行起来。对比感觉，文章提出的一人担任驾驶员，一人担任领航员能让两人更好的专注于自己的角色，更有助于学习和项目开发。
3. 在我实际开发过程中，感觉到这些原则确实很容易冲突。但是当这些原则冲突时，我们应该选取对项目本身更重要的原则，舍弃负影响更小的。并且当这些原则冲突时，法律规范和道德约束永远是选择的前提。
4. 当群体没有提供一定的宽容，是很难有这些马前卒生存的空间。比如这次的开发，我们团队的产品中包含即时通讯功能，但因为没有团队执照，所以备案未成功，也就无法投入社会使用。虽然我们并不是马前卒，但是从这也能看出，如果群体不提供一定的宽容，很多马前卒无法推广产品，也会失去生存的资格。
5. 我之前的观点并不太正确。在我实际的开发中，我其实也算用到了人种学研究法。我会把自己当成用户，去使用我们的软件，看看会有什么问题或者需要的功能，确实有助于软件的开发。

每个阶段的知识点

需求

NABCD 模型 自问五个问题：你的创意解决了用户的什么需求?你有什么招数来解决用户的痛苦或问题？你这个产品或服务会给用户带来什么好处？你的产品有没有类似的竞争者，他们的产品怎么样？你如何推销你的产品？

设计

文学化编程 文学编程自由地表达逻辑，而且它用人类日常使用的语言写出来，就好像一篇文章一样，文章里包括用来隐藏抽象的宏和传统的源代码。文学编程工具用来从文学源文件中获得两种表达方式，一种用于计算机进一步的编译和执行，称作“绕出”的代码，一种用于格式化文档，称作从文学源代码中“织出”。虽然第一代文学编程工具特定于计算机语言，但后来的工具可以不依赖具体语言，并且存在于比编程语言更高的层次中。

实现

项目进度管理 在规定的时间内，拟定出合理的进度计划，在执行该计划的过程中，经常要检查实际进度是否按计划要求进行，若出现偏差，便要及时找出原因，采取必要的补救措施或调整、修改原计划，直至项目完成。

测试

测试矩阵 测试矩阵主要维护的是代码和需求之间的关系。其中很重要的一点是：代码修改了之后，能够知道会影响多少功能，从而能够有效的缩小 测试范围，降低测试成本。

发布

逐步冻结 随着程序功能的完善，我们要让程序的各个方面有次序地“冻结”，这样才能把稳定的软件交付给用户。一般来说，程序的人机交互界面最先开始“冻结”，不能再随意修改，因为很多项目的文字信息要被本地化成多种语言，只有人机界面所用的文字和布局固定后，我们才能把这些文字交给负责本地化的部门。随着时间的推移，一些功能也可以“冻结”，这些功能都经过全面测试，所有的Bug都解决了，功能进入稳定状态，在下一个版本前不要再碰与此功能相关的代码。

维护

结构化维护 用软件工程思想开发的软件具有各个阶段的文档，这对于理解、掌握软件功能、性能、软件结构、数据结构、系统接口和设计约束有很大作用。 进行维护活动时，需从评价需求说明开始，搞清楚软件功能、性能上的改变；对设计说明文档进行评价，对设计说明文档进行修改和复查；根据设计的修改，进行程序的变动；根据测试文档中的测试用例进行回归测试；最后，把修改后的软件再次交付使用。

心得体会

经过这学期的软件工程的学习，我对软件开发有个了初步的了解。尽管在开发的过程中，我们遇到了很多困难和挫折，但我们并没有灰心。也正是这些困难，让我学习到了很多知识。
在团队开发中，我负责后端开发。我认为良好的代码编写习惯，不但有助于代码的纠错，也有助于开发人员之间的协作。作为一个程序员，对需求的理解能力也是很重要的，只有真正理解了一个模块的作用，才会写出高效率的代码，才能使整个软件项目作出来更加优秀，具备更好的安全性和稳定性。
感谢这次的软件开发，让我对开发的理解又更深了一步。